7

I've read that ideally the team is completing stories throughout the sprint and that shows gradual progression on the burndown chart. My team can only really complete stories at the very end of the sprint, so the burndown/burnup is pretty much useless.

Here are the phases of a user story for us:

Open
Development
Ready for QA
QA
Ready for UAT
UAT
Done

Can anything be done to allow stories to burndown throughout the sprint as opposed to the end? I'm sure this has a lot to do with our deployment process but would like to know what others are doing.

Improve this question
2
  • Is there a particular phase your stories tend to get stuck at? Does QA and UAT require a lot of fixes?
    – Schwern
    Jul 12, 2020 at 0:31
  • Seems like there's a "not" missing from the question title.
    – Acccumulation
    Jul 13, 2020 at 2:44

6 Answers 6

Reset to default
9

Do stories generally get done by the end of the sprint? If so then leave things alone. Tracking the sprint burndown always feels to me like micro-management. The team are responsible for meeting the Definition of Done for stories by the end of each sprint. Track the product burn-up (or burn-down) on a sprint by sprint basis, not on a day by day basis.

Improve this answer
4
  • Burndown charts are helpful for self-assessment during the sprint. They can answer if you can spend a little more time polishing a task, or if you need to move on. Devs can have a burndown chart which tracks only between "open" and "ready for qa". QA can have one between "ready for qa" and "ready for uat" and so on. It will also show if QA and UAT are frequently returning tasks to development.
    – Schwern
    Jul 12, 2020 at 0:34
  • We have a lot of spillover. Many of the stories bleed into other sprints. I would say a typical sprint is 50/50 between spillover and new stories.
    – Zack
    Jul 13, 2020 at 17:10
  • @Zack Are you discussing this issue during your sprint planning? Why add so much into the next sprint if you know you didn't complete 50% of the previous sprint?
    – nvogel
    Jul 14, 2020 at 7:40
  • @nvogel A lot of the time the stories that spillover are in a QA state. The organization places a lot of pressure on getting out releases. There's a lot of issues in the organization that prevents us from negotiating. So if many stories are in QA state we still want Dev to make progress on other stories while the spillover stories are going through testing.
    – Zack
    Jul 17, 2020 at 0:19
5

You need to look at that is happening inside of your sprint. A few things that might provide insight include:

How quickly are items moving into your sprint?

If everything is moving into progress on day 1 and 2, this may indicate that your team is trying to divide and conquer. In this approach, everything starts on day 1 and ends on the last day by design (more or less). This can happen for a few reasons. The two most common are either that is is conscious or that work is split up by skills during or before sprint planning. The first - that it is conscious - is an education problem. Our intuition fails us here because it feels right that divide and conquer is more efficient, but in anything but strictly mechanical work, it almost never is. The second is a backlog problem. You need to have your backlog item represent capabilities or problems that you need multiple skills to solve.

How much time do items spend in wait states?

You have a lot of ready states in your process. This is fine, but keep an eye on them. Do things sit in them for long periods or pile up there? You might be seeing a flow problem where people are optimizing busy-ness of the person over the flow of work through your system. Tighter WIP limits can help with this, but you can't just jam that in. You have to also consider: do the team members and their stakeholders think it is better to get something finished quickly or to keep busy? Henrik Kniberg's Resource Utilization Trap video is still the best description of this problem out there.

Is your team focused on work items or the Sprint Goal?

This is one of the toughest mindset shifts when adopting Scrum. The work items (backlog items) are incidental. They are a way to put some bounds around a particular piece of work. They are a tool. Early on, focusing on the backlog items is useful. It provides something concrete to focus on day to day. However, in time, the team needs to shift that focus to the Product and Product Increment. There are a lot of articles on this - I'm not going to do it justice in a short StackExchange post. If the team has been practicing Scrum for a little while (I'd use a rule of thumb of maybe 4 - 5 sprints), the sprint goal should be front and center in every day's conversation. The backlog items will take care of themselves.

This list is by no means comprehensive. The problem you describe is incredibly common and these are the most frequent causes I encounter.

Improve this answer
4

Seeing things like "Ready for UAT" and "UAT" in a workflow always raises a concern for me. UAT is almost always outside of the control of the development team, and often even outside the control of the development organization. These activities shouldn't be part of a team's workflow if they are beyond the control of the team.

I'd recommend making sure that your internal processes about development and testing that is within the team are sufficient to minimize the likelihood of showstopping issues being found during UAT. It's normal for feedback, but whenever the team says that it is done with the work, the work should be able to proceed all the way to production with minimal issues.

I'd also recommend performing UAT in batches. Rather than having users test and accept individual units of work, have them test and accept in a batch. This is very natural in something like Scrum, where you have fixed iterations with a regular review on a cadence. If you're doing something like Kanban, with a continuous flow, the process itself doesn't present a good opportunity, but you can define it on your own.

If UAT is finding problems that prevent acceptance, use that to fix the process. Really, UAT needs to be a formality. If you aren't producing a product that is acceptable to your users, something upstream is wrong. You don't understand what they want or need, you aren't building what they need, your tests aren't finding problems. Make it the formality that it should be.

Improve this answer
2

Two options I see:

A) Split your stories into smaller stories. B) Make your Sprints longer.

If you're unable to get your stories done in a single Sprint, then either your stories need to be shorter (note the 'S' in INVEST) or your Sprints longer. Or both.

As always, since you're doing Scrum, bring it up in the Retrospective. State the issue, hear opinions, hear others' proposed solutions, ex[plain your own, then pick one.

Improve this answer
2

From my experience, setting interim goal of individual user stories target date spread across the sprint duration helped. That would of course require each story to be well sized and individually testable. Coupled with continuous integration and delivery, it helped me a lot to overcome this problem while leading technical delivery team.

Improve this answer
-2

Also, as you are planning sprints and choosing who will do what, look carefully for the dependencies that are always present in software. We use Microsoft Project® religiously to help everyone see how everything fits.

"Longer sprints" are often quite a bit more manageable.

Improve this answer
1
  • 3
    I would be tempted to say that if you need MS Project to plan a sprint then your sprint is too long rather than too short.
    – nvogel
    Jul 10, 2020 at 21:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.