Completing all work in a sprint
Committing to a set of features and finishing the sprint with them all done
One of the features that differentiates the Scrum framework from other agile frameworks is it’s recommendation of breaking time down into sprints. The team must plan how much work they can complete in the next sprint in their planning meeting.
The team should commit to completing every feature planned in, if the team don’t think it can be achieved in the sprint then it will not be included. If possible, a feature could be broken down in order to achieve part of it within the time-box, so long as that part is valuable on it’s own
This is difficult to achieve, but holds the key to a lot of the benefits of Scrum.
What completing all work in a sprint will give the team
A team that can start to match the expectation of planning, with the reality of delivery will build a relationship of trust with their Product Owner and Customers.
Sensible estimations of work will mean that Release Plans can be forecast with reasonable certainty — which in turn will help the team to not get lost in the minutiae of individual features and goals — and look to their work fitting into bigger project landmarks and launches.
A sprint plan that is set correctly will stretch the team just enough to be a challenge, but not so much that it becomes unreachable or unsustainable. The team must be able to maintain a constant pace, and level of quality — so overworking to meet one sprint’s demands will likely cause technical debt or fatigue which will manifest itself in under delivery in future sprints. This may be needed for some exceptional deadlines, but should be the exception, not the rule.
The sense of achievement the team will feel in reaching their sprint goal will be palpable. The team should be invigorated by the challenge of completing all features in a sprint, and disappointed if they fall short.
What happens when the team fall short of their sprint plan
A very common trait in teams is being overly optimistic in how much work they plan in to each sprint. One or two sprints falling short of the planned work will be unlikely to cause problems, but leaving this unchallenged for too long can cause a variety of issues.
If a team is consistently overambitious with their sprint plan they may initially become demotivated and disappointed with their performance — when the simple reality may be that they’ve just overstretched themselves and are still performing well. Not meeting the planned amount of work will mask a lot of other issues, making retrospectives less useful and will make it more difficult to differentiate a good sprint from an average one.
It often takes a surprising amount of effort to finish the last 10% of a feature. Because of this, carrying unfinished work across sprints makes it difficult to judge exactly how much effort is required to complete this work, and how much new work can be brought in and completed.
Holding on to existing features becomes tempting when they have been started, and depending on the team processes it may be more effort to undo this work than to complete it — which will reduce the team’s ability to change priorities for their customer when needed.
After time as the team repeatedly fails to meet their expectations — the team will treat the sprint plan as a wish list of things to work on — rather than actively working towards finishing it all. If the expectation within the team is that they will not achieve all the work, then that is more likely to repeatedly become the case — even in sprints where the amount of work is achievable.
If there is too much work planned, it can easily become overwhelming — with focus drifting between different features and a mentality of ‘keeping the plates spinning’ taking over the team. Most people’s best work comes when they can dedicate time to one work item at a time and see it to completion. Working in a multi-disciplined scrum team will mean that each team member has a level of knowledge of each feature being worked on — too many features being started will distract the whole team.
Ways of helping a team meet their plan
A team consistently not meeting their planned sprint backlog, and not able to address the causes should consider whether Scrum is the best framework for them — a framework such as Kanban may be more appropriate.
It might be that estimation is difficult, and the team can’t judge the correct amount of work. If this is the case some of the techniques I wrote about recently may help steer towards a more realistic sprint backlog.
A likely cause is that the team has reached the ‘norming’ stage, and is comfortable, but not willing to ask difficult questions of themselves to increase their performance to higher levels.
A team that has started spinning the plates, can turn it around by reducing the number and size of features they plan. Collaboration should be encouraged, with team members working together to fully complete a feature, then moving on to the next — this will limit the work in progress and increase the team’s focus.
In a continuously improving agile team, some spare time should be allowed to sharpen minds towards increasing the team’s performance, and carrying out changes from previous team retrospectives. Having some skill-sets lighter on work also encourages the concept of “T shaped” working — where people work outside their main skill and comfort zone to get work completed.
We need to ensure that a team celebrates success in the right way, highlighting the completed features and acknowledging the prime directive that everyone has worked hard in the sprint. Where there might be things to change, is where that hard work has not been productive — and trying to find those reasons. There will also be some chores the team will have had to contend with — which they’d probably rather have avoided — these deserve praise, but also the team should make an effort to eliminate similar chores taking time away from customer delivery in future.
The true measure of success is features delivered for the customer, so the temptation to add work to keep all skill-sets in the team busy should be resisted. The focus of the team should be delivering the most valuable features for customers, with the minimum effort to achieve what the customer would want. We need the whole team to be busy achieving the customer’s needs, not being busy for it’s own sake.
In a good team, it can be tempting to not worry when the team doesn’t meet their sprint plan, but one of the main benefits of agile working is that everything becomes more visible. Under delivery and problems are more obvious, but positive aspects are also easier to see from the team’s delivery to customers. Ignoring the sprint plan will mean it will become more difficult for the team to have a gauge on it’s performance, making team improvements difficult to identify and measure. It’s these smaller measures which can help a good team become a great team.
