Chunk Management
Scrum requires that at the end of each sprint that you deliver a potentially shippable product increment. This means that it is functionality that is working, of production quality and should there be enough business value can be moved into production (or shipped to customers). To maximize the ability of the team to deliver this functionality, it is important to break this functionality into managable chunks.
What is the best way to accomplish this? You need to break things into thin slices of functionality that can be completed by the entire cross-functional team in a half of a sprint or less. This means that these slices of functionality (typically reflected in user stories) contain user interface (UI), business logic and database storage. It also means that it has been designed, coded and tested according to the team’s definition of done.
When I talk to teams about this, the product owner usually speaks up and says, “But that isn’t enough to deliver to customers!” That is where the “potentially” shippable product increment comes into play. While there may not yet be enough value for customers to use, and it may take more than one sprint to deliver the full release, the pieces of functionality stand on their own and can be accepted by the product owner. This is the first increment of the product for this functionality. The smaller these chunks are, the easier it is for the team—requirements are easier, design is easier, coding is easier, testing is easier. It’s easier for the team to get started, and there’s less uncertainty going into the work.
Another reason to break work into chunks is so the team can maximize what they can deliver in a particular sprint. If there is a story that takes the majority of the sprint to complete, there’s a good chance that the team may not accomplish anything in that sprint that is potentially shippable. The team’s goal is to deliver as much business value as possible, every sprint.
In addition to breaking down the functionality into smaller stories, teams also need to break down tasks into managable chunks. At every daily standup, each team member should have only one or two tasks that they are discussing with the team. Those tasks should be completed before the next standup or two. To meet those goals, tasks need to have a definite start and stop, and be a half a day to two days in length. This ensures that the team isn’t taking on too much work at a time, and that team members are able to see progress each day on the amount of work that is remaining for the team.
If you are finding that your teams are having a hard time meeting their commitment each sprint, chances are that you have not done proper “chunk management” with the team. By breaking down both stories and tasks effectively, you should be able to maximize the team’s ability to deliver and accomplish work in each sprint.