When working on a new initiative, teams often have a tough time thinking through the strategy and mechanics of how it will be delivered. Most times Agile teams will go with a burndown or velocity approach. A velocity approach negates the appreciation of what happens between start and finish. You miss the opportunity to enhance your process and better manage the flow of work.
When working on large projects, with multiple skillsets, there are bound to be handoffs. Don't ignore them. Visualize them and work at improving those handoffs. Once the team has broken the work down into thin slices of working, valuable and testable functionality. What should the team do next?
Should we start delivery and just see how long it takes us?
What level of confidence do we have that we are on the path to release on time?
How will we effectively plan each sprint?
If you've ever asked yourself one or more of these questions, read on. We will walk you through how you can use a tool and approach to bring visibility into your process. It will provide an at a glance view that maximizes support and feedback from beyond the reaches of the team.
Sequencing The Work
We all know that user stories come in varying sizes. Some are smaller, some are a little larger. However, across all stories of the initiative, they all average out to a medium-sized story with any major outliers, merged or split as needed. By acknowledging this, it allows us to use a user story as a single unit of measure. This is important when trying to build a delivery plan. This practice will also encourage the team to break down their stories to relatively the same size.
The first thing we need to do is prioritize the delivery of our thin slices of functionality. Some may be able to run in parallel and some will have a logical sequential dependency.
Building A System Of Work
Now you'll need to think about the flow of work. How do stories flow through your system? We start with an Ideation Phase where the initial peek at the work is taken. High-level scoping and estimation of work is done in this phase.
The team takes the work into the Discovery Phase where they break it down into features and stories.
Those stories then move into the Delivery Phase, where they travel through analysis, design, engineering, and testing.
Once a group or sequence of stories that make up a thin slice of functionality is delivered, they are moved into the feature testing phase.
Finally, when all thin slices are delivered they all move into an integration testing or end to end testing phase where end-to-end scenarios are tested. The product is now ready for the world and it is released!
Congratulations, you've identified your system of work! The question now becomes, how much work can flow through the system at any one time, or how much should?
Building The Plan
The team agrees on a 2-week cadence. Great! We then need to look at our historical track record of being able to deliver a user story. You'll want to make a reasonable assumption for a new team. 'Deliver' means a story moves through all phases of delivery. Looking at past experience you note that the team delivers about 3 stories per 2-week sprint. Great! You've established your throughput to use as a planning guide. For a 30 story initiative (or MVP), that comes out to about 10 sprints or 20 weeks.
Now we need to agree on what other activities will be needed for the success of the initiative. Is there any regression testing needed? Should we account for any integration testing with other teams that may take some additional time? How long will our end-to-end scenario testing take? Once we agree on these things, we are ready to start building our plan.
Let's Build It
Start by drawing a dotted-line from the date the team plans to begin delivery at a pace of 3 stories per week. Then break that line down into the stages of delivery such as analysis, development, and testing. Next, agree on the amount of time after all stories are delivered that we aim to have all of our features delivered. Then decide on how long we should allocate for additional testing. Then add in how much time we should allocate for a code freeze for example. You now have your release date. Now that the team has an initial cut at a plan, they can make tweaks and move dates around as they see fit.
A CFD can also be built the other way around by first drawing a line in the sand and picking a release date that has been set for the team. This tends to happen from time to time. Working backward can provide the team with a visual cue of if the required pace to hit this date is reasonable or unrealistic.
The objective of a CFD is not to hold the team to that plan through hell or high water. The CFD is meant as a tool that is updated weekly based on the team's reality, by the team. By doing this the team owns their plan leading to higher levels of accountability. The team can now use their plan as a reference during Sprint Planning. At times when in the weeds of the work it can be easy to lose sight of the overall goal. This gives the team a quick pulse check to ensure their local plan aligns to their global one.
How And When To Update The CFD
Every sprint, take a look at the previous sprints plan and update the team's actuals. If the team is on schedule or ahead, carry on. You've just bought yourself some time.
The team is slightly ahead in analysis, development and story testing and right on track with feature testing
If the team is behind, take some time to call out what is delaying the team and if the team needs to make any adjustments. Another question to ask is, how is the team going to make up for this delay or does the team need to consider changing the release dates?
The team is slightly ahead in analysis and development but has fallen behind in story and feature testing
Benefits of a Visual Delivery Plan or CFD
- The team feels ownership over their own plan, leading to end-to-end accountability from the team.
- It gives stakeholders an, at a glance, view into the team's progress and pace and allows them to ask questions on where they can help the team remove impediments.
- It gives the team signals early on if their pace will allow for successful delivery according to the release date. This allows the team to make adjustments early instead of finding out near the very end, where the message will be tougher to digest and changes become harder.
- It can be used as an artifact that the team uses during retrospectives to make changes that help them improve moving forward.
To Conclude
When working with your team on your next initiative, consider adding building a CFD to plan the delivery. It may seem a tad complicated at first but with the teams commitment, a good attitude and week over week iterations - it'll become a useful team artifact in no time!
We are always here to support you and your team adopt this practice. If you need help, reach out to your partners at Agile by Design.
