User story map for the second step of demand planning
Speaking of user story maps, we can know that the basic composition of user story maps must be user stories through the name. What is a user story?
User stories describe features that are valuable to users, systems, or software buyers. In order to standardize the expression of user stories and facilitate communication, the usual expression format of user stories is: as a <user role>, I want to <complete the activity> in order to <realize value>.
Therefore, user stories are a way to describe needs in agile. Unlike traditional requirements documents, user stories are more concise and do not require large text descriptions. They only need to focus on the three aspects of user roles, functions, and value realization. But, and these three aspects are indispensable, the function is to help specific roles solve problems, so what value can be achieved is very important, that is, the value-driven delivery that has been mentioned, and user stories have a famous 3C principle, card, conversation, confirmation;
- Card user stories are generally written on the card. The reason why you can combine the Kanban to do visual management when you write to watch the video. On the other hand, the card size is small and the content that can be written is limited, and many details cannot be described. This leads to the second principle conversation;
- Conversations are not described clearly in many details, so all stakeholders in the team need to maintain close communication. User stories are called stories because they are to be told. Many details are obtained through continuous communication. Communication can clarify details, and also make understanding deeper and more opportunities to tap more potential needs;
- confirmation user stories that need to be verified and confirmed, usually when using the card to write user stories, we will be at the front as ... I want ... So that's written in the format user stories, while the back will be given .. Write acceptance conditions in the form of .when...then; in
addition to following the 3C principle, a good user story should also conform to the INVEST principle. The specific content of this principle will not be repeated here, and we will return the focus to the user story map. Below is an example of a user story map:It can be seen from the figure that this is an email management product. The top (brown card) is a description of the four very important functions (organize Email, Manage Email, Manage calendar, and manage contacts). We can also understand them. For the epic story, the bottom (blue card) is a further split of the epic story, which can be considered as some core features, and the more content below (yellow card) is the user story, so we understand the user story map from the vertical It looks like a step-by-step split and refinement, but in the part of the user story, we also found that the yellow card is divided into three parts, namely release1, release2, and release3 in the figure. Here is a very core Conceptual MVP, that is, the content corresponding to release1, we call it the minimum viable finished product MVP.
Minimize Viable Products (MVP), proposed by Eric Ries in the book "Lean Startup: Growth Thinking of New Ventures", is also the most respected concept in Silicon Valley product development.
Regarding MVP, we must first clarify a misunderstanding. MVP must be delivered quickly and must be concise enough, but it is definitely not crude and low-quality. Instead, it is high-quality that can use the least functionality to verify market needs and help customers solve problems. version.
So looking back, the user story map is flexible enough, comprehensive enough, simple enough, and most importantly effective enough!
The third step is to prioritize requirements
The different versions divided in the user story map are also prioritized, but in addition to the major version division, each user story should be prioritized whether it is in the user story map or in the product to-do list. The determination of priority is not simply determined by patting your head. There are also many factors to consider, such as value, cost, market window, risks and opportunities, which is the so-called delay cost. Here is a tool for prioritization. ：M o S C o W rule, the yellow letters in a word can represent four contents:
- Must have refers to the functions that must be possessed. Without these functions, a product cannot be called a product. This part can also be mapped to the MVP we just mentioned;
- Should have refers to the functions that the product should have. However, if the functions cannot be realized due to some reasons, they can be replaced and compensated by other methods. Customers will care about these functions, but as long as the customers are satisfied in other ways, it is acceptable. ；
- Could have refers to the features that can have , but if there is not, the impact will be small. You can negotiate a subsequent version to implement it or not provide it temporarily, such as some optimized requirements or some non-functional requirements;
- Won't have refers to functions that are not needed. Such a function does not bring value, or the cost performance is extremely low, or even a reverse demand (providing such a function but the customer will be dissatisfied); in
order to facilitate everyone’s understanding, let’s give one To illustrate, if each of us is a product, which organs are necessary and which are dispensable? Using MoSCoW principle analysis:
- Must have brain and heart must be necessary, indispensable, if there is missing this product will not be complete;
- Should have hands, feet, and legs, but what if they are really gone? People can still live, this product does not seem to be powerful enough, but it can still output value;
- Could have hair and appendix are possible, hair cut may be unsightly, but it has no effect on the core function, and the appendix at least has not seen what effect it can play;
- Won't have As for what is unnecessary and should not be there, all I can think of is tumors, which are not only worthless but also affect health;
The above example may not be completely appropriate, but it is enough for us to understand the most basic concept of the MoSCoW principle, and there are many useful tools and methods for the prioritization of agile requirements. I will share more with you in future articles. .
The last two articles mainly shared with you the three themes of agile demand management: demand mining, demand planning, and demand sequencing. There are many more content about demand management, such as demand estimation, demand splitting, etc., welcome to continue to pay attention
