5

Apart from metrics like the burn down chart, how is a failing sprint identified by the scrum master (or anyone else for that matter) so that action can be taken to avoid the failure, or reduce the impact.

Addition:

Just to clarify, this question is not about identifying a failed sprint, but identifying that a sprint is failing (ie: the sprint is not yet complete and therefore not yet failed).

Improve this question
3
  • Does this answer your question? What is a failed sprint?
    – Tiago Peres
    Commented Mar 5, 2020 at 18:39
  • @Tiago Martins Peres: This does not answer the question because it asks "What is a failed sprint". I myself suggested an answer that is similar to that provided by Thomas Owens below. What this is about is trying to identify the indicators that would suggest a sprint is "failing" that would enable a scrum master to address those issues before the sprint completes, or at least prep the product owner that a "failure" is likely.
    – Yastafari
    Commented Mar 5, 2020 at 19:07
  • 1
    I see the difference and similarities. In that other question there's at least one example of a failed sprint. To answer your question, we would need to know such things.
    – Tiago Peres
    Commented Mar 5, 2020 at 19:17

3 Answers 3

Reset to default
8

I don't really like the term "fail" to describe a Sprint, but the primary objective of a Sprint is to deliver the Sprint Goal by the end of the timebox. I suppose you could consider "failure" to mean not delivering on the Sprint Goal, but I'm still not a fan of considering it a failure.

The Development Team are the best people to identify when the Sprint Goal is at risk. The Daily Scrum is an opportunity for the Development Team to inspect their progress toward the Sprint Goal and replan to maximize their chances of meeting it. If the team has concerns about their ability to meet the Sprint Goal, they should be raising these to the Product Owner and Scrum Master who, in different ways, can help the team to understand and focus on getting the valuable work done and ready for delivery.

I would facilitate the Daily Scrum by asking questions. If I don't hear the team talking about the Sprint Goal or the work associated with Product Backlog Items associated with the Sprint Goal, I'd ask about those. I would also look at time in the state, once work starts - is something "in progress" for a long time, or waiting for code review for a long time, for example, and ask about those. Some kind of visual aid is nice - I prefer a Kanban board with the Sprint Goal and work item aging visible since it can help focus the discussion on the goal and progress of work items (including blocked items). Depending on the maturity of the team, I may set aside some time for coaching on the Daily Scrum and figure out what they think would be good to help them focus on the Sprint Goal and help them set up an appropriate space with that information or visualization to guide their planning and discussions.

Improve this answer
5
  • 1
    I agree, there is no such thing as a failed sprint. Even a "failed" sprint provides material that can be used for the teams continual improvement. Also, i agree that the team is best placed to know whether a sprint goal is going to be met or not, and that the daily scrum, stand up, call it what you will, is a good indicator of this. I am just trying to get an idea what other scrum masters use to get early insight into the health or confidence of the sprint.
    – Yastafari
    Commented Mar 5, 2020 at 19:16
  • 1
    @Yasterfari I'm saying that Scrum Master's don't use anything to get an early insight into the health and confidence of the Sprint. The closest they would come is coaching the Development Team on how to effectively use the Daily Scrum to assess progress toward or risks/impediments to achieving the Sprint Goal and what to do when such risks/impediments are raised.
    – Thomas Owens ♦
    Commented Mar 6, 2020 at 10:05
  • Can you elaborate on what you have done to encourage team members to raise concerns. As you probably know, it is difficult to get people to voice their concerns, especially if those concerns are around the actions of another team member or contributor (such as a BA or a Stakeholder etc).
    – Yastafari
    Commented Mar 6, 2020 at 10:55
  • 1
    I would ask questions. If I don't hear the team talking about the Sprint Goal or the work associated with Product Backlog Items associated with the Sprint Goal, I'd ask about those. I would also look at time in state, once work starts - is something "in progress" for a long time, or waiting for code review for a long time, for example and ask about those. Some kind of visual aid is nice - I prefer a Kanban board with the Sprint Goal and work item aging visible since it can help focus the discussion on the goal and progress of work items (including blocked items).
    – Thomas Owens ♦
    Commented Mar 6, 2020 at 11:03
  • @Yasterfari I just edited that comment (and some more details, too) into my answer itself. Let me know if that's helpful or need more detail.
    – Thomas Owens ♦
    Commented Mar 6, 2020 at 11:06
1

Practice swarming

Here is a link where Jeff Sutherland, one of the co-founders of Scrum, explain the why and what of swarming.

Even though he is prescribing this as a way to improve productivity, I think it will also help to minimize the risk of a "failing sprint".

In a typical Scrum team, developers are assigned specific stories to work on. So, when the Sprint Planning is done, if there are 6 developers in the team, they start on one story each. In this method, when you look at the burn down chart, it takes what some people call a "deep dive" at the end of the sprint, even if all the stories are completed within the sprint. Meaning 6 stories could be open one day before the sprint ends and all 6 stories could get completed on the last day. This maximizes uncertainty. The Scrum Master cannot tell till the last moment whether many stories will be left incomplete.

Though you cannot eliminate the uncertainty completely, by doing swarming you will have fewer partially done stories towards the end of the sprint.

Improve this answer
0

I agree with Thomas but would like to add something small. Sometimes the development team does not have the insight or gut feeling to determine if a sprint wil be met or not. You can help them by visualising the current state of the sprint. For instance with a burn down. In my experience a graph really provides insights to developers, allowing them to take ownership of the progress

Improve this answer
2
  • This is a good idea and it took a while, but I currently do this. I say it took a while because the office manager was a little averse to rearranging office furniture, but I have each team sitting in a U shape back to back with a conference table in the middle. At one end is a large burn down graph that I update last thing everyday (I am trying to get authorisation for a PC with a large screen that hooks into the back of Jira and updates automatically). This is visible to the whole team and anyone else who happens to visit or walk by. Saves me providing a report to the PO.
    – Yastafari
    Commented Mar 6, 2020 at 10:48
  • Do you have a burn down on task or story level? I have created one on task level because that should show more activity than the story burn down. The developers in my team really like it, because of the fact that it moves every day. The burndown on story level does not move as much (because stories are bigger)
    – Bart
    Commented Mar 12, 2020 at 7:24

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.