Unfinishes tasks (Scrum)
In Scrum, What to do with tasks that are unfinished at the end of a sprint?
Principles
Don't let a slipping item determine overall success
Probably the first and most important principle: Don't let a single slipping task determine the overall delivery. This means that no single item should be so critical (a critical succeess factor, csf, key success factor, ksf), that it single-handedly determines the overall delivery, meaning that if this task doesn't get done, the whole project won't get done.
At the beginning of a project, identify these issues, and address them first. Preferably, address them before starting the project, because you surely want to know first if your project is feasable. Does that mean that no project is ever started without knowing if there is a solution? Hell there is. Like around war or emergencies.
Don't let a slipping item determine the overall planning
Don't let a slipping item determine the overall planning. This principle is similar to the principle above, but less dramatic: A slipping item might not kill the whole project, but it might shift the whole planning. This means that it is on the critical path.
Don't let that happen. No single item should be that critical, that it can mess up all the project's milestones and overall planning.
See the example about a slipping agenda item elsewhere.
Keep the planning - adjust the deliveries
A basic concept within Scrum is, that activities are usually time-boxed and the outcomes are flexible. With other words:
- Keep the planning
- Adjust the deliveries.
More specifically: No matter what, let the next sprint start on the original date. Even when the nunber of tasks is differently from what it originally was.
Get a fresh perspective
Feel like completely stuck on a task? Take a step back, get a bit detached from the problem-at-hand by doing something completely differently for a moment, take a walk, or discuss it with a collegue and get a bit more creative. Changes are, that you will easily find at least 5 ways to solve or circumvent the problem without letting the whole planning slip.
Some ideas to refresh your thinking:
- Not doing this task, is always an option
- How would somebody else handle this task?
- Make vs. buy: Do we really have to develop this ourselves? Isn't there an off-the-shelve solution available that maybe we should take a second look at?
- Sunk costs fallacy: It doesn't matter that we already spend a small fortune on this problem. What matters is: What is the most effective way to get moving again?
Be prepared for context switching
As mentioned, a slipped task should not cascade throughout the whole planning. So, changes are, that it needs to be paused. The problem with pausing a task or project is, that it might be really difficult to restart it. Especially if it is being paused for an extensive period of time. This problem is called context switching or task switching.
Solution: have a procedure at hand for context switching. This isn't rocket science. Just some common sense approaches to make sure that after a while you can restart a task again without an excessive effort. E.g.:
- Thorough documentation: Document everything relevant for restarting the task. The problem with this: I can't imagine now what I would need in three months to understand this task. To solve this:
- Regular updates: Provide regular updates on tasks and projects, including paused tasks: For me, this is the moment to further update the documentation, so that it really helps when the task gets restarted
- Task breakdown: Break down the task in smaller parts
- Include in project management: What good is perfect documentation, if as task just slips under the radar? Make sure it is incorporated in your project management system in a way, that you would find it back, as intuitively as possible.
Awareness & choice
Similar to the section get a fresh perspective above: awarness and choice go together: You're not locked-in in a dead-end street where your only option is to 'fight it out with this task until the end of time'. You always have choices, but only when you are aware of it. See the section above for ideas to get creative.
Definition of Done
There is a difference between a half-delivered issue and a scaled-back issue. Avoid the former, as you will drown in a morass of half-working stuff. The latter is ok. Make sure to deploy a Definition of Done (DoD), to make sure that whatever you deliver, is adding. E.g.:
- Functionality: All features and functionalities are implemented as specified
- Code Quality: Code is well-structured, readable, and adheres to coding standards. It may include practices like code reviews and automated testing
- Testing: The product increment has undergone necessary testing, including unit tests, integration tests, and any other required testing types
- Documentation: Relevant documentation is updated or created, such as user manuals, technical documentation, or release notes
- Acceptance: The product increment meets the acceptance criteria defined for the user stories or tasks
- Performance: The product meets predefined performance standards
- Deployment: The increment is ready for deployment and can be released to production if needed.
10% Rule
When about 90% of the planned time for a task has been spend, and it doesn't look like the task will be finished in the remaining 10% of time, you have two choices:
- Finish it in a hurry in the remaining 10%
- Update the planning, e.g., using the principles and actions from this article.
Actions
It's the job of the Product Owner, in collaboration with the team, of course, to decide what to do with a slipped task. Some ideas:
Move it back to the backlog
I believe this should be the default action: Move it back to the backlog. Be aware of context switching. So, discuss it at the review & retrospective following the sprint where this task originated.
Review and Retrospective
During the sprint review and retrospective, the team should discuss the reasons behind the incomplete task
Incremental Delivery
If the task represents a part of a larger user story or feature, consider delivering the completed portion to the product owner or end-users, even if it's not the entire feature. This way, some value is delivered with each sprint.
Carry over to the next sprint
Sometimes, a task truly is on the critical path or worse: it determines overall success. In such cases, changes are that it should be included in the next sprint.
Example: Business meeting agenda
A simple example: The agenda of a business meeting:
- An individual agenda item shouldn't let all other agenda items slip. Have it time-boxed and move on to the next agenda item when this item's time is over
- There often is such a thing as old business items that seem to get addressed before any new business items are discussed. I don't agree on this: Some old business items just need to die
- Sometimes, agenda items are continent. Two examples:
- The current agenda has an important item that depends on the minutes of the previous meeting being accepted
- First the budget needs to be agreed upon, before a project can be discussed, that depends on this budget.
Maybe the last two examples nicely illustrate how a contingent agenda items creates a vulnerability: An unwilling participant can hold hostage the whole business meeting on such an agenda item.
Example: Itanium
Arguably, development around the Intel Itanium suffered from a critical issue that could determine overall success.
Critical issue
During development of the chip, it turned out that they couldn't make a compiler that was capable of optimizing code for the unique capabilities of the Itanium. This turned out to really be an insurmountable problem.
Go or no go?
As far as I am aware, this issue was unknown prior to the start of the project. I think there were specific circumstances why this wasn't discovered earlier: It was a major, major project with lots of large computer-industry companies participating. With so much industry power behind the project, it was probably unthinkable that there would be such a problem. Even when there would have been people warning about this issue, they would probably be ignored.
Example: Dinner
When I'm cooking, the critical path is usually determined by boiling potatoes: That's the aspect of preparing dinner that takes by far the longest time. So usually, I start with the 'subtask' of boiling potatoes. Once this is going, I can divert attention to other aspects of dinner.
But what if there are no potatoes? Does that mean no dinner? Nope. It's not a critical issue. We can eat rice. Or pasta. Or I'll go to a shop to get potatoes. Or we go to a restaurant. Or we go to a gas station to eat a hot dog. Around preparing dinner, there are probably very few issues that can cause such a slip, that dinner will be skipped altogether. These are likely to be outside issues, like being on a long train or bus trip without having the opportunity to buy food.
Example: Tham Luang cave rescue
Sometimes, a potential project has a single issue that can make or break the project. Sometimes, a project has a dozen of these. Sometimes, folks know upfront about these issues, and sometimes, they do it anyway, because of specific bounday condtions. E.g.: surplus of funds; Prestige; Critical boundary conditions.
The Tham Luang cave rescue is probably an example of such a project. To mention only one such critical issue (probably the most obvious one): How to transport 16 people over a mile distance through a labyrinth of partially inundated caves, while none of them has ever dived, and some of them don't even know how to swim?.
In this case, the project went ahead because of some critical boundary conditions: 17 lives were imminently threated by a limited amount of oxygen, and upcoming rain.
They managed to pull it off. There are some griping documentaries on YouTube. Go see them!
Example: Andrée's Arctic balloon expedition
Andrée's Arctic balloon expedition refers to an expedition from 1897 to reach the North Pole by a hydrogen balloon. They would steer the balloon by using drag ropes. Things didn't go swimmingly:
Critical issues
There were at least two critical issues that could easily determine overall success:
- Balloons were made from silk and required extensive stichting. Those stiches were not air-tight and the balloon would loose hydrogen gas at too high a rate
- Drag ropes were an unrealistic way to navigate.
Go or no go?
Amazingly, the critical issues were known prior to the start of the project. The project went ahead anyway. Why? I think because of prestige or pride. One of the potential participants - Probably the coolest-headed of the bunch - declined to join. He was the only survivor.