forecastI wanted to examine how teams that regularly fail to deliver forecast work erode trust within an organisation. When a team has eighteen completed sprints without ever meeting a sprint goal then you know that there are hidden issues.

A development team in Scrum forecasts the work to be delivered in the next sprint based upon past velocity and team composition. Having unfinished work at the of a sprint is sometimes unavoidable, when this becomes frequent the team has a problem.

I think it was Mike Cohen who said ‘An estimate is your best guess of how ladamsong a task will take based upon your current knowledge’, occasionally sprints goals will not be met but this should be the exception. The late and great Douglas Adams said “I love deadlines. I like the whooshing sound they make as they fly by”. Fortunately in Scrum the deadlines are always fixed for sprints but the quantity of work delivered can vary due to many reasons including hidden complexities, unknown dependencies, sickness or misunderstandings.

Management within an organisation can view a team frequently ending a sprint with incomplete work as:

  • Lacking in the required competencies or skills
  • Unable to estimate and accurately plan its work
  • Inexperienced in Scrum and value delivery
  • Untrustworthy and unable to live up to its commitments

Software development has a poor image with many projects overrunning and massive cost increases. Agile is a tool that can be used to try to change this situation.

A team should strive to collectively achieve its sprint goal and deliver the sprint backlog. This will not always be possible as we continue to push performance and increase capability but if we are missing the sprint goal more often than not then there are some issues we can consider:

1. Datadata

The team needs to track its velocity – the amount of work completed each sprint, ideally in story points. The average velocity over the last three sprints, averaging the middle eight of the last ten sprints or a simple average of all sprints will be fine – just keep the metric consistent over time.

In addition the team needs to know at the start of a sprint planning session who will be available for the sprint and how much time that they are available for (100% in an ideal world).

Ensure transparency is maintained, if a story does not meet the definition of done at the end of a sprint then it is returned to the backlog and no points are claimed against the unfinished work. Generally do not split stories to be able to claim work, do not re-estimate remaining work and do not automatically roll work into the subsequent sprint.

Utilising a sprint burndown chart, updated at the daily scrum will also help the team maintain a realistic sense of progress.

2. Realism

The development team needs to decide how much work that they can accomplish within the sprint. It is not up to the product owner to push an unreasonable amount or for the scrum master to set a stretch goal but it is for the developers to agree as a team how much work that they realistically believe they can accomplish within the sprint. By all means use previous velocity, available skills and a chart of who is available but as a team they need to accept an amount of work to move to the done state during the next sprint.

So enough discussion, how do we fix this?

a. Retrospectivesretro

The team should focus in a retrospective on what the issues are and how to resolve them. The Scrum Master should facilitate the retrospective with the goal of the team creating actionable task
s to resolve the issue.

b. Do Less

Until we can do a task well slowly we cannot expect to be able to do it well fast. Permit the team the possibility of success by cutting the number of tasks for the sprint so that the sprint backlog size matches the team’s average velocity. When the team is able to complete the sprint goal in time it will begin a behavioral change within the team. Velocity will naturally increase for the team over successive sprints but this needs to be team driven based on the inspect-and-adapt cycle as supported by sprint reviews and retrospectives.

c. Refinement

As an experiment try spending more time on refinement and breaking down user stories. Ensure estimation is performed by the team as a whole, planning poker is ideal for this and ensure a reference set of stories exists to prevent estimate creep.

In summary, it is better for the team to predictably deliver less for the sense of achievement and the increase in stakeholder trust. Velocity will naturally increase over time but needs to be team led based on retrospective driven improvements.

If you have any thoughts on unfinished work at the end of sprint then please comment on this post or e-mail me as I would welcome any discussion.

TargetA Sprint Goal provides a focused objective for the team to produce an increment of software. It consists of a short description of a business or technical outcome that the team plans to achieve during the sprint, for example “Implement basic user profile entry (CRUD: create, read, update and delete)”.

Each sprint should be given a unique goal stating why the increment is worthwhile; this acts to align the team whilst planning, during the sprint and at the review.

Benefits of a Sprint Goal

The advantage to having a sprint goal is that it helps with –

  • Prioritisation – A goal supports the ordering of product backlog items when selecting content for a sprint. The Product Owner should select the initial goal for the sprint and then select stories to support that goal. Note that during sprint planning the scrum team may agree to change the sprint goal to reflect the work finally selected. Within the sprint the goal also becomes vital for the team when they are deciding ordering for tasks.
  • Focus – As well as providing a basis for the sprint planning session the goal provides a reason and shared objective for the increment to guide the team and enable commitment. The target is then for the team to accomplish the sprint goal and not just to complete the list of selected stories.
  • Feedback – Having a goal makes it easier to identify relevant users to review the increment and to receive quicker focused feedback. Analysing the feedback against a single goal is also easier than multiple disparate comments raised against several different stories.
  • Communication – Speaking to stakeholders and other agents outside of the team is easier when discussing what a sprint is for and helping them to decide if they should be attending the sprint review.

Creating a Sprint Goal

smartThe product owner and development team agree the goal collaboratively in part one of sprint planning and like all targets it must be SMART:

  • Specific – The goal needsto be clear and unambiguousrather than generic. For a specific goal the team must agree on what is important, why is it needed, whois required, where it’s going to happen and which elementsare required, thiscan be summarised as the five ‘W’ questions:
    • What needs to be accomplished?
    • Why is it required?
    • Who is involved?
    • Where it is to be done?
    • Which product backlog items are needed?
  • Measurable – The goal needs progress to be quantifiable, whether this is by seeing progress by the number of stories completed or by associated acceptance tests.
  • Attainable – It must be realistic for the team to be able to accomplish the goal within the sprint considering all other factors. A stretch goal by a high-performing team is fine if they decide to write it but, as always, it is the team that decides to accept the goal or not.
  • Relevant – The goal must address a challenge upon the project and move the team closer to the release or overall vision. Early sprints often focus on the reduction of risks and uncertainty (learning), later sprints generally focus on delivering customer features (delivery).
  • Time-bound – The goal must be achievable within this sprint.

Visualisation

The goal should be displayed prominently on the task board during the sprint so that the team can reflect on it at each daily scrum.

During the daily scrum the team answer three questions that reinforce the goal and work to re-align the team each day:

  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

Roman Pichler shows an image including the sprint goal displayed on the task board in his excellent post on effective sprint goals:

SprintGoal

Failing to Meet the Sprint Goal

If the goal is rendered obsolete then the product owner should cancel the sprint, this is understandably rare. Sprint goals can be missed by teams due to many reasons – insufficient understanding, over-committing, discovery of technical debt, resource reduction etc. Missing a sprint goal is an essential item to be raised during the sprint retrospective to find the underlying reason.

Accomplishing the Sprint Goal

Good work, the sprint goal has been demonstrated in the review and accepted. Another successful sprint chalked up, onto the retrospective and then straight into planning the next sprint.

Meeting the Spring Goal Early

Reality annoyingly does not always reflect estimates so sometimes a team will accomplish the sprint goal early, does this mean an early trip to the pub? Unfortunately not, the Scrum Guide states that the development team must collaborate with the Product Owner upon the scope of the Sprint backlog, this enables additional product backlog items to be pulled into the sprint.

Conclusionsprintgoal

The Sprint Goal is a great device utilised by Scrum Teams to add cohesiveness to each cycle of development. High-performance Scrum teams probably no longer need this uniting target and good luck to them, this blog is called Pragmatic Scrum for a reason so for now I will still be using a Sprint Goal.