Build products that people love, faster: Find the next most important thing with Goal-based Prioritization
The traditional backlog just doesn't cut it any more. It fails to describe why something is important and doesn't make dependencies clear. It ends up being a place to list future functionality “so you don't forget it”. The fact is: if something is important enough, it will not be forgotten. We tend to commit features to the backlog just because we can, and this spells trouble for scope management, unless we have a way to justify their value.
These days, coming up with a good product quickly is key to the success of both startups and enterprises alike. When building good new products (or improving existing ones) getting fast feedback on the most basic functionalities of your highest value features is key. Story maps, epics and all those layers of planning can be useful in certain contexts, but a team that is continuously delivering using continuous user testing and design needs something that will allow for quicker experiments, without compromising the quality of user stories (unless you have to).
#1 Decide on your goals
Chalk out a set of business goals agreed upon with key stakeholders. These should be specific enough that they can be tested frequently and progress against them can be tracked. Initially, these goals would be identified by understanding business objectives, users’ needs and how should the business meet the users’ needs in order to attain the objectives. Focus on the desired result instead of the solution. Easier said than done. Make sure to prioritize early as well as, and be ready to change your mind if the basis of your prioritization changes.
#2 Set up a Goals Wall
To achieve a model that is at once incremental (to support iterative development) and diversified (to support experiments), and maintains alignment to business goals, we devised something called the “Goals Wall”. The goals wall is a matrix where columns are the prioritized business goals (you can represent them as hypothesis, for instance) and rows are layers of refinement. It is important to remember that the strength of the goals wall lies in how easy it is to experiment and pivot. We have had success using 3 levels of customer/product attributes described in the Kano Model):
Provide (Basic) – This is basically an experiment to validate an idea, with the very basic mechanics and little else. Only do styling/streamlined interactions if that's what you want to validate. It is very unlikely you will put something at this level live for general use, but – hey! Who knows?
Satisfy (Performance) – This level includes the improvements required to make a feature marketable. It also indicates how far most of your features will be developed. It is typically the result of a few stories written based on early feedback to add polish to something that was validated at the “Basic” level.
Excel (Excite) – This is where you beat the competition. This level is reserved for the core features of a product or stuff you nailed in previous iterations and is worth doubling down on. Over time, the stories at this level become “basic” needs and new innovative features have to be added.
The Goals Wall is by nature extremely dynamic, so it may be easier to maintain it in an electronic form. When translating our real-world scenario into a tool, we wanted to start as simple as possible, and Mingle allowed for it. In order to represent stories in a matrix of goals by level, we created attributes for level types (given these are static), a tree of “goals” (a card type) and “stories” (another card type). Mingle's multi-dimensional wall took care of the rest:
Card colors represent state. The darker shade of green, the closer to done it is. This way the team can use this wall most of the time, only needing a more traditional Kanban-style wall as a secondary wall to change cards states.
#3 Map your stories to your goals
Once your initial goals are defined, start writing stories to meet them. Remember to focus first on the “Provide” level - the basic functionality that will allow you to validate the concept. It is ok to write stories further along the layers of refinement, but be sure to rank them at the right level. Be aggressive and always aim for the optimal possible amount work at each level. Take advantage of the fact that you have a natural break point between each level to make your stories as small as possible, and remember you can plan releases at each point.
When adding stories, make sure to only add those that should be placed in the top left half of your Goals Wall. There is no point adding scope that will help your products excel in non-priority goals. If you ever develop your product enough that those stories are the next most important, you will have earned so much new knowledge, that anything written earlier will have become obsolete.
#4 Track progress and incorporate feedback
Finally, you can generate a simple progress chart indicating your progress towards goals. Here the darker shade of green, the closer to production a given story is.
After each level of a goal is completed the team could develop functional tests against it, deploy to production behind feature toggles and run user-testing sessions. This allows the team to get fast feedback and iteratively build a knowledge base about the software being developed.
The Goals Wall can be an alternative for the traditional backlog in that it is a more of living document that offers specific criteria to control scope brought to a project. It is at its most useful in teams that are ready to iterate and deliver quickly, but it is simple enough to be tried and adapted to fit other environments. If you do try it, please send us feedback letting us know how you liked it! You can also get the goals-based prioritization Mingle template (the one descirbed in this blog) here.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.