Story is the main artifact used to define system behavior in Agile. They are short descriptions of functions and are usually written in the user's language from the user's point of view. The purpose of each story is to realize a small, vertical system behavior fragment to support incremental development.
This story provides enough information for business people and technicians to understand their intentions. The details of the story will be postponed until the story is ready to be implemented. Through the acceptance criteria and acceptance tests, the story becomes more specific and helps to ensure the quality of the system.
User stories deliver functionality directly to end users. Enabler stories bring visibility into the work items needed to support exploration, architecture, infrastructure, and compliance.
SAFe's requirement model describes the four-layer structure of artifacts, which outlines the behavior of functional systems: epic, ability, characteristics and stories. They describe all the work to create the expected behavior of the solution. But the detailed implementation work is described by stories, which constitute the team Backlog. Most stories come from the business and enabling features in the "planning backlog", and some stories come from the work identified by the team.
Each story is a small, independent behavior, which can be gradually realized and provide some value for users or solutions. It is a vertical slicing function to ensure that each iteration can bring new value. To divide the story into relatively small pieces, it must be done in one iteration (see the section on dividing the story).
Usually, stories are written on index cards or notes first. The physical nature of the index card establishes a tangible relationship among the team, the story and the user: it helps the whole team to participate in the story writing. Post-it notes also provide other benefits: they help to visualize works, and can be easily placed on walls or tables, rearranged in order, and even circulated when necessary. Stories can make people better understand the scope and progress of the work:
Although anyone can write stories, it is the responsibility of the product owner to approve them into the team to-do list and accept them into the system baseline. Of course, post-it notes can't be extended well in the whole enterprise, so stories are usually transferred to ALM (Agile Lifecycle Management) tools quickly.
In SAFe, there are two types of stories, namely user stories and authorization stories, as described below.
As shown in figure 1, stories are usually driven by the separation of business and enabling features.
User stories are the main way to express the required functions. They have largely replaced the traditional requirements specification. (However, in some cases, they can be used to explain and develop system behaviors, and then record these behaviors to support compliance, traceability or other requirements. )
Because they focus on topics that users are interested in, rather than the system, user stories are value-centered. To support this, it is suggested to adopt the form of "user voice", as follows:
By using this form, guide the team to understand who is using the system, what they are doing with the system and why they are doing it. Often using the form of "user voice" will often improve the team's domain ability; They will better understand the real business needs of users. Figure 2 provides an example.
Personas describe the specific characteristics of representative users and can help teams better understand their end users. Examples of rider roles in Figure 2 can be an exciting "Jane" and a timid rider "Bob". Then, the story description will quote these characters (such as Jane, I hope ...).
Although user story voice is common, not every system will interact with end users. Sometimes a "user" is a device (such as a printer) or a system (such as a transaction server). In these cases, the story can take the form shown in Figure 3.
The team may need to develop system architecture or infrastructure to implement some user stories or supporting components of the system. In this case, the story may not directly contact any end users. These are success stories that support exploration, architecture or infrastructure. Enabling stories can be expressed in technology rather than user-centered language, as shown in Figure 4.
There are many other types of empowerment stories, including:
Like user stories, enabling stories are usually displayed by displaying acquired knowledge, manufactured artifacts or user interfaces, stacking or simulation.
A good story needs multiple perspectives. In Agile, the whole team (product owners, developers and testers) have a common understanding of what to build to reduce rework and improve throughput. The team uses behavior-driven development (BDD) to collaborate, define detailed acceptance tests, and clearly describe each story. A good story needs multi-angle thinking:
Writing a story together can ensure that all viewpoints are considered, and everyone has a * * * understanding of the story's behavior, and the results are reflected in the story description, acceptance criteria and acceptance tests. The acceptance test is written using the domain language and behavior-driven development (BDD) of the system. Then, the BDD test will be automatically executed and run continuously to maintain the built-in quality. BDD testing is written according to system requirements (stories), so it can be used as a deterministic statement of system behavior rather than a document-based specification.
Ron Jeffries, one of the inventors of XP, is considered to be the first person to put forward 3C method to describe stories:
Agile teams usually perform acceptance tests automatically in business-readable domain-specific languages. Automation creates an executable specification to verify and confirm the solution. Automation also provides the ability of rapid regression testing of the system, thus enhancing the ability of continuous integration, reconfiguration and maintenance.
The investment model developed by Bill Wake [1] describes the characteristics of excellent user stories:
Agile teams use story points and "evaluate poker" to evaluate their work [1, 2]. A story point is a single number, which represents a combination of the following characteristics:
Story points are relative and have nothing to do with any specific unit of measurement. The size (workload) of each story is estimated relative to the smallest story, and the smallest story is given the size of "1". The modified Fibonacci series (1, 2, 3, 5, 8, 13, 20, 40, 100) is used to reflect the uncertainty inherent in the estimation, especially the large numbers (such as 20, 40,100).
Agile teams often use "evaluation poker", which combines expert advice, analogy and decomposition to create a fast but reliable evaluation. Decomposition refers to dividing a story or feature into smaller parts for evaluation.
(Please note that there are some other methods in use. ) It is estimated that the rules of poker are:
It is appropriate to have some preliminary design discussions. However, spending too much time on design discussion is often a waste of energy. Evaluating the true value of poker lies in agreeing to the scope of a story. This is also a kind of fun!
The speed of the team in the iteration is equal to the sum of all the story points of completed stories that meet the definition of completion (DoD). With the continuous cooperation of teams, their average rate (story points completed in each iteration) will become reliable and predictable. Predictable speed helps to plan and limit WIP, because the number of stories undertaken by the team will not exceed the range allowed by its historical speed. This method is also used to estimate the time required to deliver epic, characteristics, abilities and promoters, which can also be predicted by using story points.
Competency refers to the part of the team ratio that can actually be used for any particular iteration. Holidays, training and other events will prevent team members from contributing to the iterative goals in some parts. This reduces the maximum potential rate of the team in this iteration. For example, a team that delivers an average of 40 points per iteration, if team members take a week off, their maximum ratio will be adjusted to 36 points. Knowing this in advance, the team only promised a maximum of 36 story points in the iterative planning. This also helps to predict the actual available capacity of each iteration in the PI during the PI planning period, so that the team will not overcommit when building the PI goal.
In the standard Scrum, the story point estimation of each team and the resulting ratio are independent affairs within the team. From the perspective of scale agility, it will be difficult to predict the story point size of larger epics and characteristics when the speed benchmarks between teams are very different. In order to overcome this problem, the SAFe team will first calibrate a starting story point benchmark, on which all teams have roughly the same story point definition. There is no need to recalibrate team assessments or ratios. Calibration will be performed when a new agile release series is launched.
Standardized story points provide a way for stories and rates to reach an agreed starting benchmark, as follows:
Example: Suppose a 6-person team consists of 3 developers, 2 testers and 1 PO, and there are no leave and holidays, then the estimated initial rate is 5× 8 points =40 points/iteration. (Note: If one of the developers and testers has a part-time job, it may need to be reduced).
In this way, the story points of each team have certain comparability. Management can better understand the cost of story points and more accurately determine the cost of upcoming functions or epics.
Although it is a good thing that teams tend to speed up over time, in fact, this number tends to remain stable. The speed of the team is influenced by the change of team size and technical environment far more than the change of productivity.
Smaller stories will lead to faster and more reliable implementation, because small projects are faster, less changeable and less risky in any system. Therefore, splitting a larger story into smaller stories is an essential skill for every agile team. This is not only the art of incremental development but also a science. Leffingwell's agile software requirements [1] introduces ten ways to split stories. The following is a summary of these technologies:
Figure 6 shows an example of use case scenario segmentation:
As described in the article "Security Requirements Model", this framework applies a series of artifacts and connections to manage the definition and testing of complex systems in a lean and agile way. Figure 7 illustrates the role of the story in the overall situation of safe.
In scalable agility, stories are usually (but not always) created by new features. And every story has an acceptance test and maybe a unit test. Unit testing is mainly to ensure that the technical realization of the story is correct. At the same time, it is also a key starting point of test automation, because unit testing can be easily automated, which is described in the paper Test-Driven Development (TDD).
Note: Figure 7 uses Unified Modeling Language (UML) symbols to represent the relationship between objects: zero to many (0...*), one to many (1...*), one to one (1) and so on.
Last update:171February 20 19