On Friday, September 25 I had the honor of presenting at the dsmAgile event in Des Moines, Iowa. In case you missed my presentation, Analysis Across 5 Levels of Agile Planning, you can download the slides from this post. The entire presentation covered 18 different techniques, approaches, and mental models for analysis across the different Agile planning horizons.
The entire presentation was built around the construct called the “5 Levels of Agile Planning.” At this point, I’m not entirely sure where these 5 levels originated, but they are talked about by practitioners from many organizations and consultants from numerous firms.
Here are two important things to know about the 5 Levels.
One: The 5 Levels of Planning are ALWAYS ACCURATE but at varying levels of precision.
Two: The 5 Levels of Planning are practiced by THE TEAM. Levels 1 & 2 are not reserved for leaders, Level 3 is not just the PMO, etc. etc. – All 5 Levels are practiced by THE TEAM. Have questions, please comment on the post.
When the 5 Levels are Used
I took the time to remind attendees that we are really looking to practice the 5 levels of planning within the “construct” phase on a value stream. Here are a few key points about the value stream & the context of how the 5 Levels of Planning fit in.
- The “initiate” phase is focused on decided three things1) Should we do this work?2) Are we ready to do this work?3) Can we start this work?
- There are a few criteria that help you know if you should move from “initiate” to “construct”.
- Vision is understood
- Success measures are defined
- Product Owner is prepared
- Funding is secured
- Team Members are available
- The “construct” phase is where all the incremental delivery occurs.
- For brand new teams this work often starts with an event called Sprint 0 or Iteration 0 where they come together, create working agreements, form team bonds, get through Levels 1 – 3 of Agile planning, and ensure their 1st two iterations of stories are in a “ready” state.
- Once complete with Sprint 0, they can begin the incremental delivery cycle we all associate with traditional Scrum or Kanban practices. It is important that teams always come back and revisit the “Release Planning” activities to baseline expectations with stakeholders for what will be delivered when.
- Lastly, after any given release (or perhaps at an 8-12 week cadence), teams should pause the delivery cadence for Innovation & Planning, re-align on the Vision & Roadmap, and create a new Sprint Forecast / Release plan for the next MMFs or MVPs that will be delivered to customers. This time-boxed activity may feel similar to Sprint 0, and once complete, the team will re-enter an incremental delivery cadence.
You might already be familiar with MOSCoW analysis. It is a prioritization classification method where items are grouped by Must Have, Should Have, Could Have, or Won’t Have. Kano Analysis is similar in that it is a classification method as well. It is often used for prioritization, but is truly centered around best understanding customer satisfaction. Instead of the subjective nature for something that “cooooould” or “shoooould” be, Kano provides an explicit model for determining the importance of features in terms of customer satisfaction.
If you research the model, you can learn more about the way the Kano grid helps make this determination by asking the “functional” and “dysfunctional” questions for a single feature. Here is an example:
- Context = eCommerce site
- Feature = Product Comparison
- The Functional Question = Hi shopper, how would you feel if you were able to compare products while shopping online? The response, “I would Expect to do that.”
- The Dysfunctional Question = Hi Shopper, how would you feel if you were not able to compare products while shopping online? The response, “I would Dislike that.”
- The Result = Must Have. By finding the intersection point on the Kano grid, you’re able to determine the Kano value for this feature.
It is a great technique to employ when determining which features to include in a release.
If you’ve read much on user stories you know that there are 3 parts (actually 4 parts).
1. The Who
the end-user you are looking to satisfy
2. The What
the function the user is looking to accomplish.
3. The Why
the reason the user needs it.
4. The Acceptance Criteria
how we will know we have met the end-user’s needs
While the “what” is definitely a critical part, the “why” is often more important because if gives you context for what the end-user is truly trying to accomplish.
Impact Mapping is an approach for exploring customer/user goals and then deriving the actual functions/features that are needed in order to accomplish those goals. As practitioners close to the technology solutions, its far to easy to jump straight to the solution definition. The great thing about impact mapping is it forces us to be uber-clear on the Goal & Why customers need things. Remember, the highest priority is to satisfy the customer! (see Agile principles).
Remember, even though I review 18 potential ideas for doing analysis, you don’t (and shouldn’t) leverage all of the techniques all the time. Good Agile practitioners have lots of baggage (not the negative emotional kind), and understand the right technique at the right time. So, don’t drown yourself in documentation and extra artifacts in an effort to try and be better. Think about the customer, make them your highest priority, and derive elegant solutions to meet their needs!