Team not showing progress on tasks

Ask yourself why it is a problem that the team does not show progress/ the burndown is not looking amazing. Are there concrete drawbacks for the team caused by this intransparency? Or are there concrete advantages for the team when they increase the transparency? Team internal and team external.

Then talk to your team and convince them that they will benefit from increasing the transparency. Or maybe you realize that you already are transparent enough and it is only your personal wish to further break down tasks. Normally I'd say that tasks should be smaller than one workday. But there may be situations when it is better to have larger tasks.

So: Analyze the situation, convince yourself of what is the right thing to do and then convince your team. This way you as SM drive the inspection/adaption but you don't force it.

Through the first 2 sprints, and into the 3rd sprint, your assessment is that it is going very well. That is good, although highly unusual.

Is the team delivering on their forecast each sprint? Is their work high-quality? Are their end-users (Product Owner, customers, etc) pleased with the work product? That is also very good.

So getting to your question, which you posed as "your" challenge, is around sprint transparency. A few questions for you:

1) Why is it important to you that the burn-down charts don't resemble a healthy sprint? Is anyone else impacted by the lack of transparency, considering that the team is delivering each sprint?

2) Why is the focus on completed tasks anyway? The focus should be on completed stories. Agile Principle #7: "Working software is the primary measure of progress.". Customers are not interested in completed tasks, or that a story is 50% finished. They are interested in having a completed product in their hands that meets their requirements.

3) If you are the Scrum Master, you need to understand your Command and Control behavior as a detriment to the team and Scrum adoption. This behavior is a manifestation of mistrust, plain and simple. In your words:

"if I don't push them... things just don't get done"

"If I'm not on their case often..."

This is destructive behavior.

4) Why is it important to "show" progress on a daily basis? Who is the audience that needs to see this, and why do they need to see it? Again, this to me is a huge red flag indicating a lack of trust in the team


From my personal experience, it is extremely unlikely for newly-formed Scrum teams to embrace beneficial practices early in their Agile journey. To expect a new team to accept and excel at everything thrown at them is foolish. As a scrum master, you need to exhibit soft skills, encourage your team, suggest ways to improve that are backed by sound reasoning and examples. Never insist on certain behaviors or practices with the team - such actions will be counterproductive.

One of my favorite quotes is from Lyssa Adkins: "The team's bumbling is better than your perfect plan".

Take that to heart, and good luck.

Thanks Michael and Timothy - really great feedback. I'm a new scrum master and still learning, so it's great to get this kind of advice.

So perhaps I can give a better (and more accurate) description of the state of the project and team. When I say it's going really well, what I mean is that the business is really appreciating the value of scrum. The sprints have not been highly successful with the accepted stories, but the methodology has brought to light many risks and challenges that were previously not visible to the business. So all in all the business is impressed with the progress despite the sprint outcomes being sub-par, and they now appreciate the amount of work involved in what they assumed was something relatively simple.

From a team perspective, we have two very experienced consultants, and two consultants learning on the job, so there is a lot of shadowing going on. We're still in the stage of setting up systems and infrastructure, getting ready for development, so scrum is a little more challenging than it would be with pure development work - there are MANY organisational impediments which don't allow the team to deliver based on their commitments. Unfortunately the corporate red tape slows resolution of impediments down, but I'm working hard on this.

That being said, this is the first agile project in the business, so there is some change that needs to happen at an exec level. This is a high profile project with high visibility., and a lot of people want to be sure that things are moving forward. For that reason, there are a lot of stakeholders interested in the burndown charts. The challenge with this is that if no task progress is shown over a period of 2 or 3 days, then stakeholders start wanting to become more involved in scrum meetings to see what is going on and whether the team is actually pulling their weight or not. Obviously that's not a good thing...

So in short, we are using scrum for setting up environments which is not the same as software development. Pretty much every story is a technical requirement and not yet a business requirement. Only once that is done can we get going with the "real' work that the team is keen to get to, and which scrum is better suited to.

Point taken about my command and control tendency - I will work on this :)

Scrum Teams operate at a high level of trust. It sounds as though the wider organization would like to be able to trust the Development Team to control its own delivery risks, and so they take an interest in the burndowns. That's not unreasonable, even if jumping in on team events is not the way to encourage the desired agile behaviors.

Do the Development Team understand that a healthy burn rate indicates how delivery risk is being managed throughout the Sprint, and that a demonstration of this control can help build trust?

It looks like that stakeholders are interested in viewing the progress of work and it is a fair request. The progress can be shown at release level (Sprint Review) and within a Sprint, burndown chart is just one of the way of showing progress within in sprint.

Also Development Team should understand that by showing progress they are respecting the Transparency aspect of Empirical process

Another option for Scrum Master is to facilitate a meeting between the stakeholders and Development Team so that Dev team can understand the need of stakeholders and find out a way to satisfy that, not necessary with the burndown chart.

Try to be a facilitator and not be a communication channel between the Dev Team and stakeholders..

One challenge I have is that the developers are putting the tasks together, but often don't show any progress on those tasks for a few days at a time, so the burn-down charts are not looking amazing. I've asked that they start breaking tasks down into smaller chunks, but my pleas seem to fall on deaf ears...

When this happens, usually the team would be unable to complete the stories as per their agreed definition of done or they have to rush to complete them toward the end of Sprint. I would let the team go through the sprint and use the retrospective to look back and work out ways to improve. Getting the team to spend some time in the retrospective and come up with a set of working agreements/ norms (if not done already) could make it easier for you to get the team's commitment