Keep the remaining work of the burndown chart to the ideal line as much as possible.
As you may all agreed the sprints are not going as expected always.
What you should do as a scrum master when you see the trend of the remaining work line going up in the middle of the sprint? here are the circumstances
- There a is task of 10 points and the assigned developer not be able to even start.
- No other developer in the team also not able to help him and only one week to end the sprint.
here are the possibilities I'm thinking right now, but you always welcome to come up with a better one.
- Inform the product owner and keep it going as it is. Do not move the task to backlog or adjust the remaining time.
- Purpose: to record that team doesn't complete the work in the given estimation.
- Inform the product owner and set the remaining time to zero.
- Purpose: this will take down the remaining work closer to ideal line. Give an indication that impediment has been handled. And easy to identify if that remaining work line goes up again as it has kind a reset now, when there any other scope creep or impediment occurs in the remaining days.
I think the burndown chat can be used as an indicator of how well you mange the sprint. So I like the option one. But I'm kind naïve here. your expert thoughts are highly appreciate.
What you should do as a scrum master when you see the trend of the remaining work line going up in the middle of the sprint? here are the circumstances
@Jeewan Geeganage, The burndown chart is not the Scrum Master's responsibility. The Development Team should be able to manage their own work. The burndown chart is just a tool to help them assess how they are progressing in the Sprint.
Also, it appears to me that there is too much focus on bringing the burndown to the ideal line. Isn't that like gamification? How does that bring Transparency over the situation?
What you should do as a scrum master when you see the trend of the remaining work line going up in the middle of the sprint?
Do the team see it? Are they able to interpret what they are seeing, and upon this inspection, adapt accordingly?
@SteveMatthew agreed. The development team update the remaining work when task is complete or end of the day. Let me collaborate more..
Assume that remaining work of a task is way over at the end of the day due to may be bad estimation or scope creep.
Then developer inform scrum master and continue the task as it is the high priority. And that should get Scrum Master attention anyway as it may up the burn down.
And Scrum Master noticed another task assigned the same developer and won't be able to complete. Then what is the best thing to do.
- Move the task to backlog and inform stakeholders
- Set the remaining time zero, allow burn down to indicate future impediments. (This on already handle)
- Keep the burn down as it is.
@IanMitchell Yes. They do understand and adjust remaining work by inform Scrum Master.
The whole idea is when developer sees he has no work capacity left for a particular task, sets the remaining work as zero or available capacity for that task. In that case he has to inform Scrum Master for the transparency.
Or Scrum Master should do this when he sees the burn down is going up?
Difficult to tell, because the context is confusing. What is a task? What do 10 points mean? How can a developer be assigned to a task in Scrum? Why is it not the team who updates the backlog? How does the team decide (should they?) which backlog item will not be delivered? Is the Scrum Master unilaterally making decisions?
due to may be bad estimation or scope creep.
@Jeewan Geeganage, Is there such thing as bad estimation? An estimate is just an estimate, it doesn't have to be accurate. If it is accurate, then is it really an estimate? Now, there is nothing that says you can't have an additional scope but that leads me to ask, do you have a Sprint Goal? As long as the Development Team is able to meet the Sprint Goal, the additional scope/scope creep shouldn't matter as long as the Increment still meets Done and is potentially releasable.
Then developer inform scrum master
Why does the developer have to inform the Scrum Master? Does the developer or Development Team report to the Scrum Master? Do you see the problem here?
And Scrum Master noticed another task assigned the same developer and won't be able to complete. Then what is the best thing to do.
In the previous statement, you mentioned that the developer informs the Scrum Master, why can't the Development Team decide what's the best thing to do? Why can't they negotiate the scope with the Product Owner? As per your understanding can you elaborate on why the developer should keep informing the Scrum Master?
One more important point, if you are using an electronic tool for the burndown, then moving or marking to zero just makes no sense because there is some other way the burn down gets updated in these tools. This is one reason why I reemphasize why we shouldn't pay too much attention to the burndown chart. It's a good tool, but I can see that many people are overly obsessed with being as close to the ideal line as possible.
Yes. They do understand and adjust remaining work by inform Scrum Master.
Why is it necessary for the team to inform the Scrum Master of this, when it is the team who should understand and adjust their work?
The whole idea is when developer sees he has no work capacity left for a particular task, sets the remaining work as zero or available capacity for that task. In that case he has to inform Scrum Master for the transparency.
How would the Scrum Master make use of the transparency you describe? Who ought to inspect and adapt the plan of work?
Or Scrum Master should do this when he sees the burn down is going up?
Wouldn't it be better if the Scrum Master coached the team to self-manage, and to inspect and adapt for themselves?