Learning by example is easy, so let’s take this way. Imagine a software development team working on a fitness app. We will follow them through a couple of sprints and learn along the way.
Sprint 1 Planning
Nobody wants to spend too much time planning and detailing, so the team quickly decided to tackle the “Manage the user account” feature during this sprint. Let’s go!
End of Sprint 1 /
Sprint 2 Planning
The team finished just a part of the planned work – an account opening. In this situation, they usually decide to “just continue working on it,” but then somebody just started asking the questions:
“What is the purpose of the sprints if we don’t deliver any value at the end of the sprint but let the features spread across multiple sprints?”
“If we didn’t discuss enough details of this task, how can we estimate when it will be delivered? I mean, at least roughly?”
Indeed, sprints should enable us to deliver frequently and be more flexible, but in this way, none of it really happens…
So they discuss the requirement in more detail and split it into smaller features:
- Account opening (already done, so they just renamed the original task to this one)
- Change personal data (new task created, and they decided to do it in sprint 2)
- Account deletion (new task created and put into the Backlog for future work.
End of Sprint 2 /
Sprint 3 Planning
Yes! They did the “Change personal data” feature and immediately delivered it to the Product manager for acceptance test.
Encouraged by this process improvement, they immediately decided to work on the “Account deletion” task during Sprint 3. Again, without a proper detailing…
End of Sprint 3 /
Sprint 4 Planning
Failure! Almost nothing of “Account deletion” was implemented ☹. It proved to be way more complicated than they thought at the beginning. The reason is that they didn’t discuss the task complexity (multiple databases, SEPA,…) timely.
So, they are together with the business people at Sprint 4 planning meeting, discussing what to do. They realized that the current manual deletion procedure was not so bad considering the massive effort they would have to put into implementing “Account deletion” to be automatic.
At that point, they decided to abandon this task completely and stay with a manual procedure for some time. Let’s tackle some more urgent tasks in Sprint 4!
What about abandoned unfinished work from Sprint 3?
Yes, they spent a whole Sprint 3 for nothing! This is a very bad outcome and should be avoided. One good way to prevent it is to discuss the task in enough (not necessarily too deep) details before starting work on it.
What they have learned?
Letting the big features spread across sprints is very bad. It makes you unable to deliver value frequently. It also makes your business unflexible because you cannot change your priorities between sprints.
For this reason, the team should always discuss the requirements in enough detail so the big tasks can be split into smaller parts. Break them down to the extent that they fit into a single sprint or even smaller. In this way, you will rarely experience a situation where one feature spreads across sprints.
But, if it still happens to have some unfinished part at the end of the sprint:
- Reshape the original requirement so it represents only the finished part
- Discuss the unfinished part of the feature. If you still think it is worth implementing, create a new task(s) for it and put it on your Backlog. It can be pulled immediately into the next sprint if it is a top priority, or it can wait on the backlog according to its importance.
Business Agility in the Age of AI 