When I work with new teams on an ART, I go over the concept of working like stairs on getting features done in a PI along with stories in an iteration. In this blog, I am going to focus more on the feature like stairs concept and how teams should focus on getting features done within their PI.
The goal is to work on features in the order of priority within the PI. Think of a relay race. You do not finish the race unless the baton crosses the finish line.
We want to get the first priority (our baton) to Done which is our finish line within our race, the PI. This approach looks like stairs; as we do not move onto the next feature until the first one is finished.
Example A shows the typical pattern of starting on features in parallel, working sporadically on them throughout each iteration. This tends to happen as we try to move the work to the people versus the work to them. This could be due to the traditional waterfall approach by cherry picking from the list or skillset deficiencies. We worry more about busy people versus delivering value.
Example B shows when we only focus on the first priority and finish it before starting on the next. This follows the agile practice of moving work to the people and delivering value as fast as possible. We work to reduce any impediments by utilizing the ranking of features, having the right skill-set composition within the team along with cross-training that allows us to move people to the most important work we need to deliver. It is important to prepare and create a strategy for this before and during PI planning. Having this in place allows for a smoother implementation.
Here are some key benefits for the stair approach:
- Ensures features are getting done in the order of importance
- Reduces technical debt to allow to promote code based on the definition of Feature Done
- Decreases the risk of the number of features incomplete at the end of PI that impacts the team and ART predictability rate