Sprint Burn-down Chart

[@sgeorge1642]

By far the best video on KZbin for explaining burn down charts. Thanks.

[@NattapongPUN]

Superb, This is one of a great burn down chart analysis for the team's performance.

[@raviprasad88]

One of the BEST Video on Sprint Burn Down Chart with almost possible scenarios. Kudos to you Sir for such a amazing content. I might not need any other Video on Burn down. Respect to you Sir !!!

[@AgileDigest]

Thank you Ravi

[@Tsl-p5h]

This is one of the best videos. thanks. AS exp SM I always getting panic whenever anyone questions me on this .

[@NadineFreder]

What a clear and great video! Thank you very much, for bringing all the scenarios in.

[@samiahassan4499]

Such an amazing video with lots of real life scenarios. Exceptional ✨

[@virajdesai1919]

Cleared all the doubts with those real life scenarios.

[@AgileDigest]

Thank you

[@rajivagrawal5363]

I found in all your videos (as saw related to scrum concepts), explained everything in very simple manner with complete information. Thanks for putting complete information with simple examples to understand. Great work!

[@AgileDigest]

You're very welcome!

[@harimvn]

Excellent Explanation on different scenario based which are so practical..ThumbsUp..and Its for every Agile team to watch and understand in depth assessing the Burndown charts .. Kudos Kuldip

[@clairecarey8004]

Really so helpful, I am a new to role SM. Whilst I previously worked as a lean consultant and systems thinking coach, this has more tools as part of the role. Thank you for sharing your insights

[@JayanthChennai]

Thank you so much Niladri sir for offering real time case studies.

[@shrinivaschalwadi8507]

Very detailed vieeo with excellent clarity of idea.. Easy to understand explantion based on real time scenerio. Pls bring more such video

[@sambitpadhy7275]

Awesome clarity about BURN DOWN chart

[@AbhineetKumarabhi]

Thanks Agile Digest, your contents are more practical, really helps

[@ganeshramamoorthy6059]

Nicely done with practical real-life examples and responses. I enjoyed it. I too prefer hours to track a sprint after it has started. However, for planning a sprint backlog and estimating product backlog, story points (or a relative sizing model) is generally better. I say "generally" because when multiple teams work together on a product backlog, having a common measurement (other than hours) might be difficult. Well done!

[@mthokozisimtolo8910]

Amazing work! Thank you for the clear and detailed explanation. This is highly appreciated!

[@lww1143]

Thank you for this excellent video. Nice job explaining the burn down chart scenarios. THANKS!

[@RahulGupta-fg3wd]

I love these clips. Great job done Niladri.

[@bhawnabhasin]

Great explanation , all your videos are very helpful.

[@thulasiramansriramulu3668]

Awesome. Never seen a video explained in so simple understandable way. Thanks.

[@gopia9572]

What a coincident I'm watching this video on 11-12-21 as the trainer created Burn-down chart for the same timeline. :) :)

[@AgileDigest]

Great 👍

[@indirapriyadarsini4439]

Very well explained all the aspect of Burndown... Very practical and crisp voice was an add on . 🙏

[@AgileDigest]

Glad you liked it!

[@mohamednawas3326]

Wow....!!! Great presentation...!!! Terribly Awesome...!!! The scenarios matches real time...!!! Hope More videos are in PIPELINE..!!!

[@AgileDigest]

Thank You

[@ratanpandey7524]

Best way of explaining

[@q8246500]

Thanks for such a wise lectures

[@adamasworld02]

Excellent and well concise details. Thank you 😊

[@Rokib-dq7hs]

Very informative and vety clear deliberation.

[@ceciliahaynes2230]

Great presentation! One of the best I have seen....

[@AgileDigest]

Thank you Cecillia.

[@shyamalaraman6414]

Excellent explanation!

[@poonambairagi5701]

Very informative thanks for sharing

[@mingsqtt]

I like to comment on the use of story points for the y-axis and also to avoid having a zig-zag burn down visual. We can still update the remaining story points on daily basis instead of updating only after each story is fully burnt as a whole. When estimating the remaining story points, we just estimate by ratio of completion. For instance the initial points for a story is 10, after 1 day, if we think only 20% is completed, the remaining story points would be 8, and so on. We can also increase the remaining story points in the middle of a sprint as soon as we have realised the initial story points were under estimated.

[@poojachawla9597]

More than the Agile content, I am really amazed at your Powerpoint Skills. How excellently you present all the content. Is their a Video on how to create such beautiful presentations? I would love to have some video or templates. Really great job Niladri. Thanks a ton !!!!

[@AgileDigest]

Thank you Pooja

[@noorkhawaja]

Excellent video. Thank you.

[@AgileDigest]

Glad it was helpful!

[@gobbaka]

Good Presentation reference to Burndown chart with the multiple scenarios

[@mohamedlabri6014]

Thank you for that very helpfull tutorial!

[@MrSonyw595]

very nicely explained as always

[@naughynags]

amazing learning sir.tq

[@shekhawatravi]

Crisp and clear explanation. thanks for sharing this,

[@rajagopalvenkat922]

Thanks for explaining the concepts in a down to earth manner. I watched a couple of other videos regarding burn down chart, it was very confusing, but your video clarified all the doubts. Keep going and share your knowledge, All the best Mahapatra sir !

[@Naveen_Y]

Very nice and detailed explanation sir

[@AgileDigest]

Thank You

[@manishubana2107]

Thanks for the detailed explanation.

[@vickisham2887]

Fantastic explanation

[@AgileDigest]

Glad you liked it

[@KiranVarri]

Exceptional 👍🤩🙌👏👏👏

[@AgileDigest]

Thank you 🙌

[@sathyanarayananramanathan2517]

Thanks for the video. Appreciated.

[@chinedufelix2472]

Good explanation , my team burn down in story points at the same time create subtask for each story, that way we don’t burn down properly. Please how can you help me to have my burn-down chart look good . Also we have assigned story point to business and production support work, while tasking out the stories how can we do with production n business work been unknown work for the Sprint the team work on

[@gopikrishnapalempally6893]

awesome explanation!

[@swatisnigdha5249]

Very well Niladri..

[@ramkushwaha]

Very well explained ...

[@tunapradhan3595]

bhai , excellent content and explanation..

[@tunapradhan3595]

May I ask a question, which screen recording tool you used for the tutorial ?

[@AgileDigest]

Camtesia

[@dilyanavelinova-chonova548]

Excellent video! Thank you!

[@AgileDigest]

You are Welcome

[@backester_singhaman6914]

should have divided this video in two or three part what is burn down chart and what are the scenarios surrounding it.. I been eyeing this video for some time and finally watched it now 😅😅✌

[@AgileDigest]

Yes You are right, Next time onward will try to split it accordingly.

[@nayersadek8968]

Thanks for this amazing video, if you could please do video about Burn Up chart that we be helpful!

[@nkrao-vl4ro]

excellent video

[@angle_mishaa6820]

Excellent 👌

[@AgileDigest]

Thank You

[@samsonakinsanya1810]

Great job 👏

[@kalyanchilkamarri7298]

Great videos Niladri. However in my experience I have observed the Dev Team not logging their hours diligently every day. They have been logging the hours that were committed. Some days they worked less and some days they worked more. So I am not sure how the Burn Down chart really helps in predicting any crisis.

[@jackymyriam7222]

very informative, thank you.

[@susangee2706]

Good Explanation of scenario ..Really appreciated . If there are more number of P3 or P4 issues during testing how do we handle it if in scenario 1 - we are the middle of the sprint . Scenario 2 if we are n the last few days of sprint closure

[@AgileDigest]

In both the cases, its good that you are raising defects to avoid pushing the code to production with defects. and in both the cases, your approach should be "finish first" pick the top priority story fix all its bugs make it done, then pick the story next in priority. If the team can not fix all the bugs of any single story, and your definition of done says, you need to fix all bugs including P3 & P4, then you may end-up completing zero stories at the end of the sprint. Its even better to not adding any increment than adding a defective increment. Post sprint work on the gaps at requirement and Developers end to minimize the defect leakage, Estimate the effort for P-Review or Unit testing, have retail requirements with SMART Acceptance Criteria. that will reduce the number of defects in future.

[@acap56789]

I'm sure it is all a matter of opinion, but I wouldn't advise using hours. The fact there is always fluctuating time remaining being recorded tells us that any estimation in hours isn’t to be relied upon. Given no two tasks are the same when you add in people, skills, availability or simply the time of day, then hours is not useful information. Relative estimation has been proven to be the best approach by larger brains than us. The capacity line is a useful visual of people working too many hours. But as a good scrum master, I don’t need a chart to tell me that. If developers are writing code in week one and testers in week two then you have bigger problems. Stories should be small (lookup INVEST) ideally a days effort and at a max 3 days effort as an exception. This situation would imply the stories are either long-running or broken into technical tasks and therefore no longer independent. Either way, this is an indication that there is something wrong with the stories. A story on completion should be deployable, if not then its Definition of Done should mean it has been fully tested. Although a burn-down chart looks better in hours and makes you feel like you’re in control, you’re not. This is the classic misconception of precision over accuracy. A stepped burn-down is ok provided the stories are small and therefore the steps are small. The stories in the example are not. Also, the team can’t claim the value of those points until the story is done and the work is complete. If testing is going on in week two from a story started in week one, there is something wrong with the test approach or deployment pipeline. Follow INVEST when breaking down stories, order them in an order that makes sense to develop, so that failure to deliver the last few stories doesn’t prevent you from releasing. Even if all the functionality is not visible to the user, there is still technical value doing this to de-risk the next sprint. By taking this approach you will always deploy at the end of the sprint even if you don’t meet your sprint goal or anticipated velocity. But you will deploy, and you will have useful information for the retrospective to work on, to help you refine your practices and get to that sustainable velocity.

[@AgileDigest]

Thanks Andy for this big explanation. Yes It may be matter of Opinion. For me if you are using Story Points for burndown (Team Level), don't spend your time to refer your burndown its of no use. There is no point of maintaining or referring a chart that is not able to provide any direction to improve. Yes for a Program Level or Solution Level you can use story points for release burndown or feature burndown. This video is intended for people who are entering into Agile world. If they start using Story Points for burndown, the burndown will become a formality for them. I strongly suggest and advice Don't and never use Story Points for your Burn down, Use it with Hours or don't use it.

[@amritanair2452]

Awesome video, very clear and concise! I had a query though. An agile team typically estimates stories in story points. Do we also expect them to let us know the hours they will take to complete a story? Would really like to know more details as to how the hours are decided. Thanks a lot for your help.

[@AgileDigest]

Estimating on hours is not mandatory.working with only story points is more agile centric, However few organization and management needs the efforts also to be calculated, then the team may need subtask or task to estimate effort hours. Remember there is no relation between story point and effort hours.

[@JayanthChennai]

Kindly go through "Capacity planning video" by Niladri Mahapatra. Thanks.

[@piyushsinha1659]

First and foremost thank you. Secondly, I would request to explain advantage of plotting burn down chart based on story points

[@AgileDigest]

at team and sprint level you may not get much benifit of story point based burn down, However at release level or PI level you can users story point based burn down.

[@vijendrasingh161]

With story points on the y-axis, you can see the rate at which the functionality is getting accepted by Product Owner. This shows the real progress of the scrum team in delivering the product against the capacity they have consumed.

[@chellappansubramanian1550]

Simply Waaav....

[@AgileDigest]

thank you

[@neerajarao9520]

Well explained 👏. May I know why average burndown shows negative

[@AgileDigest]

Not sure what do you mean by average burndown

[@pesilpathirana8878]

Could you please do a video for release planning and road map??

[@dhavakumar8942]

Thanks for the wonderful explanation... Also, may I know what happen in the chart, if the team is burning the actual hours but story point is not getting burning down because of some technical or other issues... Because this chart is showing only the hours burning... So shall we include both story point burning and hours burning the same chart using BI tools.?? So that we can easily understand how many story points pending in the stipulated hours.,. Kindly correct me if my thought process is wrong... :)) thank you Niladri... !!!

[@AgileDigest]

Hi Dhava, Dont mix Story Point and Effort Hours, Those are two different measurement unit. You can have two separate Burndown without relating them. Ideally follow only one either story Point or Effort Hours

[@dhavakumar8942]

@@AgileDigest Yes ji. You are correct. later only i realized.. thank you..

[@bmk5217]

Thanks for the video. What makes red line going down? Is it a task is done by developer (not live yet) or the task is on Live?

[@AgileDigest]

Remaining amount of time

[@DimaWild]

Thank you

[@rajeswarikv9396]

Awesome

[@manjunathaiahbeldonimath952]

very good!

[@shivanigaddi7078]

Thanks for the detailed video. For example, if time estimation provided by the developer for a task is 10 hours but it took him 15 hours to complete it, should he change time estimation? Will it update the original time in y axis in the report/graph? Also, if all the tasks are not completed by the end of sprint, how will SM/ PO will be able to analyse what particular task was changed/took an extra time because of which sprint goal was not met?

[@AgileDigest]

Original Estimation should not be changed. Update the remaining estimate accordingly. If any of the single task is not completed at the end of the sprint. The entire story will go back to backlog.

[@keyurpanchal6452]

What about kickoff meeting on start , estimation of hours timing are consuming in first day. 10 days 7 to 8 days are provocative l. Not a 10 days

[@FadeEcomonics]

Perfect!

[@AgileDigest]

Thank You

[@JayanthChennai]

How can we create burn-down chart based on working hours on Jira ?

[@kiran7161]

Thank you so much for detailed explanation Niladri. Have a question. 1. I am using Jira server version, am not able to find burn down chart with hours. I see velocity in y axis is Story points.

[@salilbhatnagar4662]

hello Kiran, I guess there is a tab to configure the estimation of the stories in which its mentioned and have option: Estimation Issues can be estimated when in the Backlog to get an idea of how much work is being committed to in a sprint. Read more about estimation and tracking. That will have options to select them as story points or hours.

[@peterivarsson9267]

Why not follow both story points and remaining hours?

[@pallavisharma2269]

Suppose every team member which is 5 in ur example work 6 hr per day. so total burned hours will be 30 hour for a day, if all have update ALM tool. SO burn down chart will be burned accordingly? Im new in this so trying to understand the concept.

[@AgileDigest]

Yes that is the ideal situation and reflect in ideal line. The actual line represents after the work how many is remaining

[@Varghese_B]

Sir your video is so good, can you guide me how these things work in TFS?, Also how to coordinate with client many things I want to learn. I am new to this job role.

[@AgileDigest]

Thank you. Please drop us a mail at [e-mail] for further details.

[@arukokate]

Can you explain Story points allocation ? like for 1 hr Task , 4 hrs task and a day task

[@AgileDigest]

Story points dont have any relation with Hours

[@JayanthChennai]

Can we create capacity line in Jira, if yes, How?

[@kyawswehan]

But as you use Y axis as hours, how would you know which hour is for which Story point?

[@AgileDigest]

Not required to relate. And don't relate.

[@kyawswehan]

@@AgileDigest So if sponsor complain that not enough work is done, and if you want to show him the burnt down chart, how will you tell him what are the functions remaining to work on and what has been completed?

[@AgileDigest]

@kyawswehan your ALM tool should have that transparent

[@kuntaladutta4836]

Do you prepare student for PSM/CSM also ?

[@AgileDigest]

I prepare student to understand Scrum and agile. Those student can appear for psm or csm. But out intended goal is not to target any exam while preparing.

[@kuntaladutta939]

@@AgileDigest Can you please help me. After i seeing most of your videos i am glad that i came across of it. Thank you. I feel no other organisations or institution can make me understand better than this.

[@veeramanirevolt]

If we work on story points how can we convert story points to hours to map it down in burndown chart and is there any way to convert story points to hours in general?

[@AgileDigest]

There shouldn't be any relationship between story points and effort hours.

[@shanmagesh1309]

Is there a video for sprint burn-up chart ?

[@AgileDigest]

Not Yet

[@abdelkadermouedden780]

Hello sir, your presentation are perfect please can you tell me what software did you use for it ? cordially.

[@AgileDigest]

It's all power point

[@abdelkadermouedden780]

Can you send me this power point file please !

[@AgileDigest]

Can you please explain the purpose.

[@abdelkadermouedden780]

I want to take its template

[@usefulent9257]

BUT .. CODING IS AN INNOVATIVE OR CREATIVE TASK . WE CANNOT PREDICT HOW LONG IT WILL TAKE . IN CASE OF COPY PASTING , TESTING KIND OF REPETITIVE WORKS, WE CAN CALCULATE .JUST BY MULTIPLYING.

[@AgileDigest]

We show the creativity, when we don't know precisely what to develop. Or how to code the moment you will get the clarity of what to develop, you will separate the innovation from increment. Remember the lean principle, minimize waste, deliver as fast as possible, ...

[@keyurpanchal6452]

Burn down is a controversial issue. Tracking a people to work in toilet as well

[@AgileDigest]

Really? Who says that? It's not for tracking what or how much the team worked. It's for look into how much is remaining, maximize the amount of work not done. See, there are many controversial topics. First, understand the concept, then check if it is useful for your team, organization, and great. Otherwise, move on.