Storie Points x Burndown

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?

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!

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.

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?

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.

Hi,

I have a similar issue. In a 2 week sprint (10 business working days); we usually allow dev work to go on until the 7th working day of the sprint. The rest of the 3 days are meant for testing. 

In JIRA, our workflow looks like this:-

TO DO               IN PROGRESS                   READY FOR TEST                       DONE

The devs mark their stories to READY FOR TEST by end of 7th day. The tester moves it to DONE either before or end of 10th day (last day of the sprint). This way my burndown goes for a toss. Please suggest how this can be improved. As of now, we don't create any sub-tasks in the stories. My current manager says, create sub-tasks when there are multiple developers working on the same story which is not the case here. Please suggest.

Thanks

Why is work being batched and driven by schedule, rather than being carefully limited and pulled by flow?

Aarti - The burndown chart is telling your team the truth, why would you want to manipulate it to not provide transparency for the team?  Because testing is part of 'done', I would expect a flat horizontal line for at least seven days, then a sharp vertical drop late in the Sprint.  The burndown is telling you that your flow needs to change.

Your team's cycle time is at best 7 days, because it takes at least 7 days to finish coding, then there is a hand off for testing.   Seems to me that you have a lot of risk in your flow of work, because defects may be found late in the Sprint.

Your team has a bottleneck in the flow of work - no testing can happen for 7 days.  Many modern Scrum teams are cross functional to be able to have the developers take on some or most of the testing, whereby the developers build quality into their process (XP, TDD, BDD, CI/CD, Pairing, Refactoring etc.).  This eliminates the handoffs and bottlenecks.  How might the developers pair up with a tester early to swarm a backlog item to complete the entire item early, before moving to the next item?

Chris

In addition to Ian's and Chris' comments, your sprint flow can be greatly improved by splitting up your items into smaller ones.   it sounds easier than it is, but there is a ton of literature and suggestions out there for doing so.

Smaller units of work will allow for earlier completion of development work, and subsequently an earlier engagement around testing.   See if you can design sprint items that can be developed in 1-2 days.

Great thread & very helpful information! 

One question regarding breaking down stories into smaller units - how have you all seen this work with higher environment testing?

ex: If I am a product owner and responsible for testing in a UAT environment, wouldn't this increase my work since I'd have to test the individual pieces and then also test the whole feature once all of the smaller pieces are in UAT? It sounds like I'd be doing double work testing the same features multiple times. Is that anticipated? 

If you're doing that you are a developer as well, because you share in the accountability for ensuring work is Done. What do the other Developers think about automation and how it may help them meet this commitment?