Storie Points x Burndown

Last post 01:58 pm February 15, 2018
by Timothy Baffa
5 replies
Author
Messages
02:36 pm February 9, 2018

Hi, guys.

I need help about how to improve my burndown with more real situation in my Sprint.

I work with Jira, and I have some stories in a Sprint estimated with 3, 5, or 8 points, for exemplo.

My time, normaly ends de stories on the last day of the Sprint. So.. .during my 2 weeks of Sprint my burndown never get down.

How can I make my burndown get down every day, in Jira. Considering high point in the Stories. 

 

 

 

 

08:25 pm February 9, 2018

Why not limit work-in-progress so the team focus on completing one thing at a time, and thereby evidence better throughput? Have the team conducted a Retrospective in which they have considered their ability to collaborate more effectively?

10:12 pm February 9, 2018

You could also consider burning down tasks or task hours, but that would not solve your WIP problem Ian called out, as all of your Sprint Backlog Items would still be finishing on the last day or the Sprint.

Does your team have a Sprint Goal that they can focus on, replanning their work daily in the Daily Scrum?  Have you taught your team that multi tasking wastes time, and by focusing on one Sprint Backlog Item at a time would make them more productive?  If it isn't possible for all team members to work on one story at a time, then maybe two?  That's why we limit WIP - it cuts down on context switching which is a waste.  And limiting WIP also exposed bottlenecks (aka impediments).

All the best!

10:24 am February 12, 2018

The Burndown Chart is a tool designed to provide transparency of progress towards the Sprint Goal. If this tool uncovers a potential problem, is it really prudent to change the way the tool works?

Ian and Chris have already pointed out that you potentially have a WIP-Queue problem there. Limiting the number of work-in-progress items is one potential solution, as they've suggested. Another thing to look at would be reducing batch size, i.e., is it possible for you to split your stories further, so that you can deliver smaller items? Bear in mind though, that everything you deliver should provide value for the user.

05:39 pm February 14, 2018

 

Thanks a lot, Ian, Chris and Julian.

My bigger challeng is that my deliverys are APIs, basicaly. We have other teams that will consume this aplications.

Exemplo:

Storie: Customer´s API. 5 Points.

SubTask 1, SubTask 2, SubTask 3.....

The team ends the subtasks frequentily, but my burndown just get down later, almost in the end of the Sprint when all the tasks are done.

I had read that I can work with storie points and subtasks in hours. I can configure my burndown to works with hours, the result would be a real situation about my team works.

But now, I work just with story points.

I aprecciate all the coments but I believe that the problem is the way that I am working with Jira or with the concept about stories, tasks and burndown.

@Julian, tn this case I don´t know how to split this kind of storie.

Did you already work with just integration deliverys?

 

 

 

 

01:58 pm February 15, 2018

My bigger challeng is that my deliverys are APIs... tn this case I don´t know how to split this kind of storie

Are you trying to complete the entire API within a sprint?   Can you have a story to only enhance/create a portion of that API, and have the other team try to consume it in the same sprint?

Can you divide API work by platform?   Can you split API stories by who would consume it?

Ask yourself how you can create smaller items that can provide quicker feedback, and how you can reduce handoffs and waiting around delivery of functionality.