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 !!!
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!
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
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
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 !!!!
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!
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 !
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
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.
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
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.
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.
@@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?
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.
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.
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.
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 😅😅✌
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.
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.
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... !!!
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
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.
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.
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.
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.
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.
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?
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.
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?
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.
@@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.
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.
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, ...
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.
By far the best video on RUclips for explaining burn down charts. Thanks.
This is the best explanation I found!
Superb, This is one of a great burn down chart analysis for the team's performance.
Such an amazing video with lots of real life scenarios. Exceptional ✨
What a clear and great video! Thank you very much, for bringing all the scenarios in.
Cleared all the doubts with those real life scenarios.
Thank you
Awesome clarity about BURN DOWN chart
Nice. Very detailed information. Thank you so much.
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 !!!
Thank you Ravi
This is one of the best videos. thanks. AS exp SM I always getting panic whenever anyone questions me on this .
Very detailed vieeo with excellent clarity of idea.. Easy to understand explantion based on real time scenerio. Pls bring more such video
Excellent explanation!
Great explanation , all your videos are very helpful.
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!
You're very welcome!
I love these clips. Great job done Niladri.
Very informative thanks for sharing
Thanks for such a wise lectures
amazing learning sir.tq
Fantastic explanation
Glad you liked it
Very nice and detailed explanation sir
Thank You
Very informative and vety clear deliberation.
Excellent video. Thank you.
Glad it was helpful!
Exceptional 👍🤩🙌👏👏👏
Thank you 🙌
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
Best way of explaining
Wow....!!! Great presentation...!!!
Terribly Awesome...!!!
The scenarios matches real time...!!!
Hope More videos are in PIPELINE..!!!
Thank You
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
Awesome. Never seen a video explained in so simple understandable way. Thanks.
Thanks Agile Digest, your contents are more practical, really helps
very nicely explained as always
Thank you for this excellent video. Nice job explaining the burn down chart scenarios. THANKS!
Thank you so much Niladri sir for offering real time case studies.
Amazing work! Thank you for the clear and detailed explanation. This is highly appreciated!
Very well explained all the aspect of Burndown... Very practical and crisp voice was an add on . 🙏
Glad you liked it!
bhai , excellent content and explanation..
May I ask a question, which screen recording tool you used for the tutorial ?
Camtesia
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 !!!!
Thank you Pooja
Excellent 👌
Thank You
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!
Excellent video! Thank you!
You are Welcome
Great job 👏
Excellent and well concise details. Thank you 😊
excellent video
What a coincident I'm watching this video on 11-12-21 as the trainer created Burn-down chart for the same timeline. :) :)
Great 👍
Good Presentation reference to Burndown chart with the multiple scenarios
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 !
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
Thank you for that very helpfull tutorial!
Thanks for this amazing video, if you could please do video about Burn Up chart that we be helpful!
Great presentation! One of the best I have seen....
Thank you Cecillia.
Crisp and clear explanation. thanks for sharing this,
Thanks for the video. Appreciated.
Thanks for the detailed explanation.
awesome explanation!
Very well explained ...
Thank you
Very well Niladri..
very informative, thank you.
Awesome
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.
Simply Waaav....
thank you
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
How can we create burn-down chart based on working hours on Jira ?
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
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.
very good!
Could you please do a video for release planning and road map??
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.
Well explained 👏. May I know why average burndown shows negative
Not sure what do you mean by average burndown
But as you use Y axis as hours, how would you know which hour is for which Story point?
Not required to relate. And don't relate.
@@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?
@kyawswehan your ALM tool should have that transparent
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.
Yes that is the ideal situation and reflect in ideal line. The actual line represents after the work how many is remaining
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.
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.
Kindly go through "Capacity planning video" by Niladri Mahapatra. Thanks.
Why not follow both story points and remaining hours?
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 😅😅✌
Yes You are right, Next time onward will try to split it accordingly.
First and foremost thank you. Secondly, I would request to explain advantage of plotting burn down chart based on story points
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.
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.
Can we create capacity line in Jira, if yes, How?
Perfect!
Thank You
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... !!!
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
@@AgileDigest Yes ji. You are correct. later only i realized.. thank you..
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.
Thank you. Please drop us a mail at support@agiledigest.com for further details.
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?
Remaining amount of time
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.
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.
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.
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.
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?
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.
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?
There shouldn't be any relationship between story points and effort hours.
Is there a video for sprint burn-up chart ?
Not Yet
Can you explain Story points allocation ? like for 1 hr Task , 4 hrs task and a day task
Story points dont have any relation with Hours
Do you prepare student for PSM/CSM also ?
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.
@@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.
Hello sir, your presentation are perfect please can you tell me what software did you use for it ? cordially.
It's all power point
Can you send me this power point file please !
Can you please explain the purpose.
I want to take its template
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.
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, ...
Burn down is a controversial issue. Tracking a people to work in toilet as well
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.