Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Storie Points x Burndown

Last post 05:05 pm January 16, 2022 by Ian Mitchell
11 replies
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.


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.

06:40 am February 23, 2018



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.





06:23 pm February 23, 2018

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

07:55 pm February 23, 2018

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?


09:08 pm February 23, 2018

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.

07:57 pm January 14, 2022

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? 

05:05 pm January 16, 2022

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?

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.