Abstract: How do you feel about itemization of requirements?

At one time, probably in the years after 2010, agile became more and more widely known in the country, and user stories became almost standard as an important agile requirement practice. However, practitioners have always had a lot of questions and confusion about it, especially the controversy of user stories and use cases, which has run through almost the whole development process in China. Although in my opinion, their relationship is easy to understand and simple, Craig Larman made it quite clear in his workshop, which is also my personal opinion.

To put it simply, the following user story practice is really good, and practitioners tend to like it very easily, although the practice is often quite deviated, and the first is that very few people really strictly follow its three-paragraph statement.

The second, of course, is the confusion that arises among agile practitioners in larger organizations: how do you manage the number of stories? What about finished stories? How should cross-team stories be handled?

The main methods practitioners use to solve these problems are User Story Mapping and Impact Mapping, for which you can refer to the books of the same name by Jeff Patton and Gojko Adzic, the founders. User story map solves the problem of the relationship between big stories and small stories, as well as the issue of story publishing schedule. The impact map focuses on thinking and solving problems related to business goals, user behavior, and system functionality.

Unfortunately, even when both practices are applied, there are still problems that are not completely solved.

When I worked in my previous company, I did agile transformation service for a bank R&D center for a long time. Shortly after I entered the project, I was asked a question: “What do you think of itemization of requirements?” . That was the first time I heard the term “requirements itemization,” but I thought it was an interesting name and a good one. Was also felt that extend customer lands and terminology concept helps to practice themselves, so I just put a user story, story map, map, such as large part of UML diagrams, the ATDD agile practices together, as well as the value proposition, design thinking and practice, as a “demand entry” the operation of the meaning behind the name. From my perspective, the blending of these practices is the key to moving requirements itemization from Definition to Operational Definition (deming, Operational Definition).

Why the sudden mention of requirements itemization?

Because it’s my idea of a way to make user stories more effective and grounded.

First of all, the requirement structure of itemization is as follows:

We can think of it as roughly corresponding to Epic, Feature and Story, but in essence, these three levels are different in nature, rather than EFS, which is mainly different in the size of requirements. The requirements concept resides in the problem domain, clarifying the business question to be solved, such as why did you start this project? Why develop this new version? Items are in the solution domain, and while it may be tempting for r&d departments/teams to equate items with system features, in reality, it is entirely possible and absolutely possible to solve a problem without implementing any features. Subitems are located in the implementation domain and are primarily used to solve problems of collaboration between development teams, such as between different modules or between the front and back ends. For smaller teams, where there is no complex division of labor, there is probably no need to use subitems. Further down, the team can be divided into specific tasks to solve the problem of division of labor and collaboration among internal team members.

The requirements concept, item, and sub-item levels, each of which is a user story, are treated according to the quality requirements of the user story, namely the 3C and INVEST principles. They all have acceptance criteria and then refine test cases, test automation (I personally insist on 100%), ATDD. As for the relationship between acceptance criteria and test cases, you can see my different views with Teacher Lu Yi in this article: Examples, Acceptance criteria and Acceptance Tests.

What can these three levels be?

  • Concept: market hot spot, user pain point, competitive product reference, etc
  • Item: End – to – end requirements, features that are useful to end users
  • Sub-items: small end-to-end requirements, or technical requirements that split end-to-end requirements into different architectural levels, modules, or teams depending on the organization, such as front-end rendering and back-end processing capabilities for an end-to-end feature

It is worth noting that the clarification of these three levels of requirements does not pursue to break down all the requirements clearly and list them before starting the next specific research and development. Instead, it adopts the rolling refresh mode of research and development while clarifying. Of course, this is the premise, in order to produce good results, this premise must be done, is to have a good input and continuous update of the maintenance of the three-level requirements structure of tools, simply speaking, agile requirements tools.

Once the requirements are clarified, they are incorporated into the plan at all levels, assuming an agile planning model. It is strictly based on the agile planning model, which usually requires early clarification of all or most requirements before development can begin. The Agile planning model emphasizes gradual refinement and incremental planning, which is similar to the requirements itemization.

In chronological order, the general process is as follows.

Identify and prioritize the core goals of the project/release, eliminate low priority, weak goals, and my personal opinion is to focus on 1-3 core goals regardless of project size or number of people. A large number of people, a large project, the concept of demand is large; With fewer people and smaller projects, the need concept is larger. However, further deconstructing along the tertiary structure, at least the sub-items can become granular enough to meet the team’s iteration schedule.

And then, you draw the scene, from the user’s point of view. User Angle, user Angle, user Angle! User ≠ Customer, User ≠ Customer, User ≠ customer! A user is an actual user of a service, product or function provided by a vendor. It is not difficult to figure out the interaction process and contact points between users and manufacturers. For example, it should be the interaction between users and Huawei, rather than the interaction between users and a huawei website or system. These combinations of interactions and contacts, called entries, are also loosely equivalent to the current term JTBD.

The part of the manufacturer in the scene diagram is divided into different swimming lanes according to the system architecture level or service level or module, and the contact points of the manufacturer in the scene diagram are refined into the interaction process of different internal systems, modules or teams, and become sub-items.

The practice of itemizing requirements is very demanding for tools, at least in my mind the 100-point standard is very demanding for tools. For the whole process above, the key is that there is a system that maintains this three-level structure, with concepts, items, and sub-items expanding requirements details at each level (like a Wiki). Requirements acceptance criteria Split test cases should be associated with automated test scripts or are themselves executable, preferably associated with previous requirements to form executable requirements. Besides easy-to-read mode, such as Wiki, Word document or form format in the system, the whole structure and nodes should also be stored in a pure textual and code-based form, which can be versioned like code and support automatic generation of complete requirement documents by tools. Any changes to requirements, tests, code can trigger the entire pipeline of validation, truly becoming Living Documentation for what the instantiated requirements stand for.

This article is shared by Kaverjody from Huawei Cloud community “User Stories are Not Silver Bullets”.

Click to follow, the first time to learn about Huawei cloud fresh technology ~