Burndown Chart not decreasing

Question

I'm revising for a Software Engineering exam and one of the questions got me wondering. It showed a burndown chart where the team had made no progress on user stories for 10 days. The question was "Outline and justify any action that the ScrumMaster may consider taking at this point".

I've thought about drastic action, like stopping the sprint. Then there is to assign pair programming to help users and to consider breaking down user stories even more. Does anybody have any other suggestions? (This question was worth four marks on a past paper).

Answer 1

There isn't enough information to give a complete answer but in my experience the first thing I'd do as Scrum Master is look at the burndown chart that plots task hours over time (rather than Story Points over time).

It's quite common to see hours being burned down correctly but Story Points remaining static. Often referred to as 'mini-waterfall' because the team are leaving testing until the end of the Sprint and so no stories are ever 'done' until the end of the Sprint.

If my guess at the scenario is correct then, as Scrum Master, I would devote time to covering why the team are working in this way at the Sprint Retrospective with a view to getting them to concentrate on getting stories to 'done' as quickly as possible and reducing WIP.

Answer 2

I personally hate abstract questions like this - since you don't actually have enough information to give a "good" answer. How long is the sprint? What have the team been doing? What's the underlying cause of the lack of progress? These are all things you would already know if you were the scrum master of the team. You should never be in the position of just looking at a burndown chart after ten days and then figuring out what to do.

For example:

• Maybe the team has been tasked with doing "emergency" tasks outside of the context of the project

• Maybe there are stories that are partially completed but not finished because of a bottleneck (e.g. stories aren't getting to done because there isn't a tester available, or a designer, or a PO for final sign off)

• Maybe the stories are too large and are taking too long - or maybe a story has turned out to be exceptionally complex and has exposed an area of the system that's a big-ball-of-mud and is hard to tweak

The real answer would depend on the actual working context. If I was forced to give an answer it would be something like:

1. Write a reminder to figure out why I fouled up and only figured out that there was an issue to be addressed ten days into the problem.

2. Write a reminder to bring this topic up in the sprint retrospective - since something bad is obviously happening

3. Figure out what the bottleneck/problem is and try and address it. If we have a team that's pretty good at self-directed problem solving I might suggest switching to a work mode where everybody swarms on a single story so we can get at least some things done.

... but the real answer is "it depends" ;-)

Answer 3

Rootcause analysis of why this is happening perhaps? is it the skills-gap? knowledge on the subject, as a team do they know how to approach these user stories, have they broken down the user stories into tasks during the sprint planning session, is the PO collaborative enough participative in the whole process?

A good sprint planning is required, and a followed product backlog grooming session too, if these had taken place they could avoid these issues.

Further more there are various techniques a team could adopt if they are new to the technical environment / domain etc, a spike on the stories or tracer bullet to get them to comfort level perhaps?

Finally allow them to fail as a team, and pick up during the sprint retrospective.

This is where a scrum master can be effective, a good scrum master would have taken the daily impediments log and been proactive to not allow this to happen.

These are my two cents. Hopefully helpful for your exams!