Strategies for Agile Product Planning
Valuable initiatives produce an observable change in someone’s way of working. Capturing a behavior change makes a story measurable from a business perspective, always opening up a good discussion. Often, the short description of a story leaves a lot of ambiguity about the scope of the change. Even when it is being discussed face to face, it may only be apparent to some the full implications of taking on the story. If you have a big chunk of work, identify underlying assumptions and think about the easiest way of proving or disproving them. Design experiments around those assumptions and turn them into user stories.
Use the experiments to build the foundation so that the rest of the big picture can be delivered with minor iterative improvements. When the deliverable is outside the zone of control of the delivery team, there are two everyday situations: the expectation is completely unrealistic, or the story needs to be more actionable by the delivery team. If a story does not fit into the expected pattern, raise the alarm early and consider rewriting it. Throw out or replace fake and misleading accounts.
Micro-stories aren’t necessarily bad, but going so deep into detail is probably overkill for anything apart from short-term plans. If you discover micro-stories on medium-term or long-term projects, replacing a group of related stories with one more significant item is probably better. Even planning to check the outcome after delivering a story makes teams write better. It has the same effect as test-driven development does on code. It provides focus and clarity and leads to better solutions.
Impact Mapping is a strategic planning technique. It prevents organizations from getting lost while building products and delivering projects. Impact Mapping communicates assumptions, helping teams align their activities with business objectives. Make the backlog hierarchical. We only break down significant items into smaller ones once we need to populate the lower levels with more information. Organizing the backlog into several tiers allows teams to reduce the number of things while providing a big-picture view. When an impact is on the map, a stakeholder believes that the change in customer behavior will lead to the business goal. When describing the purpose of a milestone — the first level of the map — focus on the problem to be solved, not the solution. When representing the actors — the second level — think about who can impact the outcome. To describe the impacts — the third level of the map — think about behavior changes you are trying to influence.
Why is the team engaged in the efforts? Identify a clear business goal with metrics to measure progress. Why is the team doing all this (rewrite)? What is the Goal we’re trying to archive?
Who is going to be impacted by this Goal? Who are the actors or different stakeholders in the project? How will the team support those people? Can they help the team archive the Goal? The higher-level definition of what the team is committing to deliver to the direct stakeholders. Impact Mapping is a technique that allows development teams to align with the business. Impact Mapping enables you to understand what you want to do with a project without getting into the details.
Impacts are not product features. For example, better mobile search isn’t an impact but a deliverable. Finding information faster is a good behavior change to describe instead. Then treat them as options, not as commitments.
Another option for prioritization is to focus on a single segment first and improve in that area. Change cues to reduce the chance of users ignoring them; create associations between the user’s existing work tasks and the product. Avoid concurrent signals that seek actions.
Build up trust, and improve initial usage experiences. Help users build habits that will make them skip the evaluation and timing parts of the funnel. Provide clear guides and action plans, small wins, and reduce the risk of failure.
A good strategy for dealing with such issues is to discuss global concerns once per milestone. This leads to a framework that applies to all work during that delivery phase so that the problems do not need to be considered for each story.
Create a pyramid of quality based on Maslow’s hierarchy of needs, and add an acceptance criterion to each level. The questions that define the pyramid levels (bottom-up) are: Does it work? (functionality and deployment) Does it work well? (security, performance, capacity) Is it usable? (usability, design) Is it useful? (behavior changes, user-level goals) Is it successful?
The delivery team wastes a lot of time tracking and managing unnecessary items — time that could have been invested more. Consider creating a checklist of expectations for global concerns such as usability or security. Small, easy wins always get prioritized over complex tasks. Activity metrics are great for measuring whether the team is working well together or not, but they can’t show real progress. Measuring progress with an activity creates a wrong set of incentives for prioritization.
Managing all this information often puts a lot of strain on product managers, who need more time to deal with day-to-day activities. When market opportunities change, the business stakeholders face a severe dilemma. Keeping the project would deliver outdated or useless features or delay work on something more significant. It’s straightforward to hide scope creep and unnecessary work in a pile of several dozen items. The story card hell problem starts when a team only has one level of abstraction in their backlog — when the backlog becomes linear.
[¹]: Impact Mapping: Making a big impact with software products and projects
