Prioritizing User Stories for Software Projects
The original purpose alignment model talks about business processes, not software features. Since you are working with user stories, the value statement (‘To…’) will most likely help you do purpose alignment, not the deliverable (‘I want…’). 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. Apply a mix of old technical and business people to represent both perspectives. This will help prevent impractical or impossible targets and challenge people’s assumptions. It is the most effective triaging system we’ve used on software projects. The model requires stakeholders to ask two questions for each item: Is it mission-critical? (Can the business run without it?) Is it market differentiating? (Does it bring customers, provide a competitive advantage, or something similar?).
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?
Consider creating a checklist of expectations for global concerns such as usability or security. Create story maps for key user activities — not for software solutions. For example, purchasing a book, booking a venue, or attending a concert are suitable activities to map out. Submitting a rating or posting to a social network site is too low — they are parts of some higher-level activity and do not deserve their maps. As the first step, identify the backbone of the story map — the horizontal axis. Break down activities into high-level steps. The steps should not imply a particular technology or a solution. Identifying measures that do not suggest solutions will allow you to develop good ideas later. Great user stories should be focused on causing behavior changes. The model is also helpful for splitting stories. If a story is too big and tries to influence several parts of the funnel, we can break it into several accounts that address individual aspects.
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 plain to 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. If a story does not fit into the expected pattern, raise the alarm early and consider re-writing it. Throw out or replace fake and misleading accounts. Micro-stories aren’t bad, but going so deep into detail is overkill for anything apart from short-term plans. Even planning to check the outcome after delivering a story makes teams write better.
