Fine grained story point burnup chart

[GaboonViper]

One of the things that I’m missing is a more fine grained sprint progress chart.

Of course I could have it I put remaining time on the tasks. The problem with that is that to me it’s not worth the effort. Aside from that, I regularly add new tasks and remove old ones because things turn out differently than I thought. So the remaining time chart would basically go up and down like a jojo. This is what’s currently already happening with the burn up chart for tasks.

So basically the only chart that really accurately represents my progress is the burnup chart for story points. Here the problem is that for bigger stories (basically anything of 5 points or more) it’s just too coarse. Only when a story is completely done it shows up in this chart, which means it basically looks like a staircase.

The point burnup chart could be made more fine grained by adding points based on finished tasks. If a story of 5 points has 5 tasks, then every finished task basically means that one point has been burned down. And even adding and removing tasks should not be too problematic, because you could just use the simple formula of « FinishedTasks / TotalTasks * StoryPoints ». I think this could really improve the chart.

I hope you guys will consider adding this.

Cheers,
Boyd

[Nicolas Noullet]

Hi,

As you explained, sprint burnup and burndown charts in number of tasks or task remaining time lose relevance when tasks are added / remove throughout the sprint.

However, what you suggest has a few flaws:
– introducing a magic formula between number of tasks (or remaining time?) and story points is questionable
– even with your proposal, adding tasks to a story would have an impact on the chart by lowering the « achieved points », removing tasks on the other hand would increase achieved points, which would result in a curve very similar to the one you get from tasks alone.

I am afraid that there is no really good indicator for sprint progress if tasks are not created accurately in advance, which is the case when there is high uncertainty. In such case, the ScrumMaster and the team should focus on daily standup meetings, discussions and visual management through the task board evolution in order to keep track of the sprint advancement and forecast failure to deliver stories on time.

By the way, in iceScrum v7, a % of advancement is displayed on « in progress » stories, which is computed according to task completion but there is no impact on story points.

[GaboonViper]

So you’re saying if I wan’t to know the progress of my team, I should either:
– Tell my team to estimate every single task. Even if I was inclined to give them this administrative burden, that means all story point estimates have just become useless.
– Use the story point chart and pray that if there are still 4 stories in development near the end, they’ll get finished in time.

[Nicolas Noullet]

I understand that your context make it difficult to follow the progress of your team and I am willing to help. However, based on nearly a decade of experience in agile project management, I expressed my doubts regarding the solution you suggested.

Here is what I suggested instead:

the ScrumMaster and the team should focus on daily standup meetings, discussions and visual management through the task board evolution in order to keep track of the sprint advancement and forecast failure to deliver stories on time.

I don’t know how you came to the conclusion that I suggested to either start using task estimates or follow only the story point charts, I did not say anything close to that.

Let me reformulate my suggestion: the very best way to follow the advancement of a sprint and the likelihood to finish stories is by looking at the task board on a daily basis and foster communication with and within the team. Transparency, communication, collaboration, inspection etc. (e.g. through visual management and meetings) are the very fundations of the agile philosophy, while charts and estimates are only additional and optional tools that may or may not assist in the process.

The above addresses the fact that you have hard time following the progress of your team. Another point that I would suggest to address is what motivates the need to follow the progress of the team, which is perhaps a tendency to fail to deliver what is planned? If this is the case, this should be addressed too and hopefully the need to follow closely the progress of sprints will fade over time as everybody involved gain confidence in the ability of the team to deliver stories.

[GaboonViper]

Sorry, I didn’t mean to come across as harsh as I did. I’m afraid I was a little hasty with my reply.

We of course do things like the daily standup meetings and stuff, I’m not interested in discussing that. I understand your concern about it, but I’m talking about hypothetical situations or experience from the past. If we’re doing things wrong, then no tool is going to help us anyway. But if we’re doing things right, a tool can make it easier.

The proposal I made, it’s close to the kinds of charts I’ve used in the past. Transparency, communication, collaboration are of course important, but we’re all still human and we tend to be influenced by our emotions. No one likes to admit they are behind schedule, so we tend to be overly optimistic about our chances. But if we’re looking at a chart that objectively shows we’re probably not going to make it, it’ll help us do something about it. Like informing the stakeholders and discussing the removal or perhaps even the addition of stories. It also means we won’t be disappointed at the end of the sprint if we didn’t make, preventing a drop in moral.

So let me explain the issues I have with the available options.

– ‘remaining time burn down chart’ is not an option as we don’t estimate remaining time for tasks
– ‘story burn up chart’ is pretty much useless because a story of 1 point is equal to a story of 8 points.
– ‘task burn up chart’ is a contender, but it’s problematic because some tasks belong to big stories and some to small ones. For big stories the tasks tend to be bigger. And as I said we tend to be loose with task creation and removal. This may change as we get more experience, but that’s the case at the moment.
– ‘point burn up’ is very tricky especially at the end as most team members are generally still finishing up their last story.

You’ve proposed the task board, but when you have 20+ stories every sprint, it’s difficult to use as an overview. Aside from that it pretty much has the same problems as the ‘task burn up chart’, as in not all tasks are equal.

That’s why I did the proposal. I’m not looking for help. I’m not expecting you to implement what I proposed, though it would be cool. I just want to make sure you understand why I think this is a useful feature. And I figured I couldn’t be the only one to think this.

Thanks for your time.

Cheers,
Boyd.

[Nicolas Noullet]

Hi Boyd,

Thanks for the clear and detailed explanation!

I agree that the task burnup chart is probably the most valuable of the charts offered by iceScrum in your case. The tendency of the curves is not relevant, as they will grow or stay constant even if works is achieved. However, if you forget about that, the chart still shows the equivalent of total task percentage achievement every day, which may be a good indicator for sprint completion. The thing that is missing as compared to your solution is the weighting of tasks according to the points of the stories they belong to, which we are cautious about because it really depends on the practices of the teams (how they estimate stories, how they split them into tasks etc).

Cheers,

Nicolas

[GaboonViper]

I think you might be right about the task burnup chart. And perhaps the weighting isn’t really as necessary as I thought, as bigger stories tend to have more tasks anyway. I’m gonna try it for a while, see how it works out.

Thanks.

Cheers,
Boyd

[Auteur]

Messages