How to handle a failed Sprint and how to avoid it ?

Let’s imagine a typical Sprint of 2 weeks duration. If the team is delivering software continuously since more than a year it means that the team had run around 26 Sprints past year. Do you think it is feasible that each and every Sprint has been finalized with success? Obviously, it is not surprising that a number of Sprints fail to accomplish the Sprint Goal. Well, even though it’s not the best scenario, a mature Scrum team is supposed to manage mentally and emotionally the consequences of a failed Sprint.

Every professional aims to be successful at personal level. Similarly, everybody enjoys  being part of a winning, successful team. Nevertheless, it is very likely that a Sprint could not achieve the targeted Sprint goal and fails due to several reasons such as bad planning, dependencies, challenging Sprint goals, changing scope etc.

In this case, Retro sessions offer great opportunities for the team to discuss democratically and openly the reasons of failure, things to improve to avoid another failed Sprint and how to make a more effective planning. In Jira system, the Sprint Backlog Items those could not be brought to DONE state are automatically transferred to Product Backlog by default once the Sprint is finalized. As a best practice, the SBIs those are still in UNDONE state ( in development stage, in test stage etc.) should be re-estimated as the required effort to make it DONE has been decreased thanks to the efforts the team had put so far. The PBIs with revised SPs should be included in the next Sprint scope unless there is a concrete change on the priorities. Please keep in mind that it should be us, the Product Owners who are supposed to decide the priority order while discussing with the relevant stakeholders.

Clearly, if the team fails to finalize    the Sprints successfully in a row, this would had a negative effect on the team’s morale. Perhaps more importantly, the reactivity of the team to a failed Sprint could erode. That’s why, Product Owners shall be extremely careful in setting S.M.A.R.T. goals. To recall what SMART refers to:

  • Specific
  • Measurable
  • Achievable
  • Relevant
  • Time-bound

Let’s imagine  the development team of Instagram’s iPhone application. A potential  Sprint Goal could be:

At the end of this 2 weeks Sprint, we are targeting to introduce archiving functionality of Stories for iPhone users and 3 out 5 beta testers should be able to recognize how to do it at first glance.

If PO sets constantly Sprint goals those are not SMART, failing could become a habit which in return could damage team’s confidence and motivation.

On the contrary, if PO sets S.M.A.R.T. targets , team could come back even stronger after a failed Sprint. The Sprint team as a whole should constantly crosscheck if the goal is clear enough and how to self-organize achieving that goal.

All in all, POs should avoid setting unreasonable targets, secure effective Sprint planning  and make sure that team stays focused and result-oriented. 

Schreiben Sie einen Kommentar