The basics of user stories. Part 3: Invest in quality user stories
Continuation of the translation. Part 1 , Part 2 .
Translation: Alexander Yakima ( www.enter-agile.com )
Independent consultant, agile-coach. In the IT industry since 2002. He worked as a project manager, program manager, as well as a site manager in outsourcing companies and as a development director at Silicon Valley startups. In 2007-2008 he collaborated with the training center Luxoft.
Invest in quality user stories
')
Flexible teams spend a significant amount of time (probably half or even more) in researching, working out and analyzing user stories as well as writing acceptance tests for them. It should be so, because it confirms the following fact. :
Writing code for an already understood goal will not necessarily be the most difficult part of product development, the most difficult is to understand what the real purpose of writing code is.
Therefore, to invest in quality story, albeit at the last crucial moment, is a worthwhile occupation for the team. Bill Wake, put in the abbreviation of INVEST 7 , to describe the attributes of a good user story 8 :
The INVEST model is fairly common and many flexible teams evaluate their skills based on these attributes. Below we offer our vision of exactly how the team should INVEST.
Independence means that story can be developed, tested and possibly even delivered by itself. Because of this, it can carry independent value.
Many of the user stories will acquire natural, consistently accumulating dependencies as the functionality of the product increases, and yet each piece can be an independent value. For example, a product can show a single entry, then a list, then organize it, then filter, add page-by-page navigation, export the list, edit items, etc. Many of these items have sequential dependencies, and yet each of them provides independent value. and the product can potentially be delivered if development is suspended at any of these points.
Nevertheless, many dependencies that do not carry the ultimate benefit, which are technical or functional, also tend to fall into the backlog - we must identify and abolish them. Here is an example of a functional dependency that is not useful:
In this example, the consumer story depends on the administrator story. Store administrator is only tested for installation, cleaning and preservation of security policy, but not testable from the point of view of applying the policy to the end user. In addition, the implementation of the administrator's story does not put the product in a potentially deliverable form - and therefore does not carry an independent utility.
By revising user histories (and system architecture), we can remove dependencies by repartitioning in a different way - in our case, by the type of security policy and by putting together the policy setting and its application in each story:
Now each story can exist by itself and can be implemented, tested and delivered quite independently.
Unlike traditional requirements, user history is not an agreement on a specific functionality, but rather a container for such requirements, which have yet to be discussed, implemented, tested and accepted. This process of discussion between the business and the team adequately reflects the legitimacy and priority of information emanating from the business, but also predisposes to research through collaboration and feedback.
In our past companies with a vertical organization structure, written requirements generated a limited amount of communication between departments and served as a record of past agreements. Agile, on the contrary, is based on the idea that a team approach is more effective in solving problems in a dynamic environment (one team, in which both technical personnel and business represented by product manager are present, instead of cooperation between heterogeneous departments of the company, is the note of the author of the translation). User history is a structured real-time tool for the effective use of this effective direct communication and collaboration approach.
Finally, the debating of user stories allows teams to achieve predictability. The absence of overly restrictive and overly detailed requirements improves the ability of the team and business to find a compromise between the amount of functionality and the delivery date. Since each story allows some flexibility, the team also has more flexibility in meeting the goals of the release, which increases reliability and increases confidence.
The goal of a flexible team is simple - to deliver the maximum benefit within available time and resources. Therefore, the use (sometimes we call it value - approx. Of the author of the translation ) is the most important attribute in the INVEST-model, and each user story should represent a certain value to the user, customer or stakeholder of the product. Priorities in backlogs are set based on the value of the story and the whole business is going through success or failing depending on the benefits that the team is able to deliver.
A typical challenge faced by teams is to learn how to write small, incremental user stories suitable for efficiently delivering value. Traditional approaches captured in us the algorithm of the functional breakdown of requirements into technical components. This “technical layering” approach in system design slows down delivery until all layers are joined together as a result of numerous iterations. Wake 9 (Wake) offers its vision of vertical rather than technical (horizontal) layering:
Creating useful stories requires us to reorient our thinking through partitions from horizontal to vertical. We create user stories that “cut” the architecture through, so that we can provide value to the user and rely on his feedback as early and often as possible.
Although usually the value is focused on the user interacting with the system, sometimes the benefits are more naturally focused on the customer's representative or key stakeholder. For example, the director of marketing for an energy company asks for a higher conversion rate for banners on the site. Although the story can be recorded from the user's point of view:
... however, in order to provide a clearer vision of real value, it would be more natural to write a story from the point of view of the marketing director:
Another difficulty that teams encounter is the justification for the benefits of technical storia such as refactoring, upgrading components, etc. For example, how to determine the value of a product such as:
Formulating the value of a technical solution as a user story helps bring business to its business. For example:
In these last examples, the value is evident both for the user, and for the product manager, and for the stakeholders, as well as for the team.
A good user story is simulated. Although there can be any size in the backlog, in order for it to be implemented and tested in one iteration, the team must be able to provide a rough estimate of its complexity and the amount of work needed to complete it. The minimum investment in estimating a story is determining whether it will go into the framework of a single iteration. Additional accuracy in estimating will increase the team's predictability.
If the team is not able to evaluate the story, then the story is marked as too large or that it is not sufficiently defined. If it is too big for the evaluation, then it should be broken down into smaller stories. If the story is too weakly defined to be simulated, then a functional spike should be applied to reduce uncertainty, so that one or more user-assimilated user stories are obtained. (Each of these cases is discussed in detail in the following chapters).
One of the main advantages of estimating user stories is not only an idea of ​​the exact volume, but also the ability to isolate hidden assumptions, missing acceptance criteria and clarify the team view of storytelling. Thus, the dialogue accompanying the process of estimation is just as important, and perhaps more important, than the evaluation itself. The ability to assess a user story is highly dependent on its volume, as we will see below.
User stories should be small enough to be executed in an iteration, otherwise they will not represent values ​​or will not be considered as completed at the end of the iteration. Although even more compact stor give more flexibility and productivity. There are two main reasons for this: increased throughput and reduced complexity.
Increase bandwidth
As is known from queuing theory, more compact packets pass through the system faster. This is one of the key principles of lean manufacturing and is reflected in Little's law (Little):
In a stable system (where bandwidth, i.e., the amount of work that can be done per unit of time, is constant), we must reduce the amount of current work, in order to reduce the cycle time (time interval between the beginning and end process). In our case, this means that fewer, more compact user stories will go through the development cycle faster .
Moreover, when the system is fully loaded, it can become unstable and the problem can become piled up. In heavily congested systems, large packets move through the system disproportionately slowly, as bandwidth drops. (Imagine a highway at rush hour. A motorcycle's chances of moving normally are much greater than those of cars and trucks — it is much easier to maneuver compact objects when driving in a loaded system.) Because development teams are usually almost full, or even higher ( 80-120%), they also fall into the "rush hour".
When the load reaches about 80% and more, more objects increase the cycle time (slow down) to a much greater degree than smaller objects. Moreover, the variation in the cycle time increases, that is, it becomes more difficult to predict when a packet can actually leave the system — an illustration of this is shown in Figure 1 below 10 . In turn, this low predictability destroys plans, commitments, and trust in the team.
Figure 1. Large packages have longer cycle times and higher variation.
Complexity reduction
More compact user stories go through the development process more quickly, not only because of their proportional volume, but also because of less complexity , and the complexity is non-linearly dependent on the volume . This is best seen in testing, where the extensiveness of the test system required to validate the functionality grows exponentially relative to the amount of the functionality itself. This corresponds to the recommendations for the development of clean code, namely, Robert Martin [Martin 2009] offers the following rules for the functions of the system:
This is one of the main reasons why the Fibonacci sequence (that is, 1, 2, 3, 5, 8, 13, 21, ...) is so effective in estimating user histories - the estimate of labor costs grows nonlinearly with increasing task volume.
On the ratio of volume and independence
The question of the relationship between volume and independence is quite legitimate, since it seems logical that less stori increase the number of dependencies. However, smaller stori, even with a slight increase in dependencies, deliver higher bandwidth and provide more operational feedback from the user than large user stories. Therefore, supporters of Agile always lean towards smaller stories, and then make them even smaller.
In full Agile, the entire code is tested , hence the testability of the story. If the story turns out to be untestable, then it is poorly formed, or unnecessarily complicated, or, perhaps, depends on other user stories in the backlog.
To make sure that the story does not get into the iteration, if they are not able to get out of it (that is, to be successfully tested), many flexible teams today use the approach: "first tests". This originates in XP communities that use Development Through Testing (TDD) - the practice of writing automated unit tests before writing code that must satisfy these tests.
Since then, this philosophy has been applied in developing the criterion for accepting storytelling and the necessary functional tests before coding itself. If the team knows how to test the story, then they probably also know how to implement it.
Due to testability, user stories fall into the same “pitfalls” as the requirements. Fuzzy words such as fast, manage, beautifully, cleanly , etc. are easy to write, but they are extremely difficult to test, because they mean different things to different people, and therefore should be avoided. And despite the fact that these words provide a certain level of talkability, restricting them with clear boundaries will help the team and business to synchronize the expectations of the result and avoid big surprises.
Translation: Alexander Yakima ( www.enter-agile.com )
Independent consultant, agile-coach. In the IT industry since 2002. He worked as a project manager, program manager, as well as a site manager in outsourcing companies and as a development director at Silicon Valley startups. In 2007-2008 he collaborated with the training center Luxoft.
Invest in quality user stories
')
Flexible teams spend a significant amount of time (probably half or even more) in researching, working out and analyzing user stories as well as writing acceptance tests for them. It should be so, because it confirms the following fact. :
Writing code for an already understood goal will not necessarily be the most difficult part of product development, the most difficult is to understand what the real purpose of writing code is.
Therefore, to invest in quality story, albeit at the last crucial moment, is a worthwhile occupation for the team. Bill Wake, put in the abbreviation of INVEST 7 , to describe the attributes of a good user story 8 :
The INVEST model is fairly common and many flexible teams evaluate their skills based on these attributes. Below we offer our vision of exactly how the team should INVEST.
Independence
Independence means that story can be developed, tested and possibly even delivered by itself. Because of this, it can carry independent value.
Many of the user stories will acquire natural, consistently accumulating dependencies as the functionality of the product increases, and yet each piece can be an independent value. For example, a product can show a single entry, then a list, then organize it, then filter, add page-by-page navigation, export the list, edit items, etc. Many of these items have sequential dependencies, and yet each of them provides independent value. and the product can potentially be delivered if development is suspended at any of these points.
Nevertheless, many dependencies that do not carry the ultimate benefit, which are technical or functional, also tend to fall into the backlog - we must identify and abolish them. Here is an example of a functional dependency that is not useful:
1) As an administrator, I can set user password security rules so that users will be required to create and maintain secure passwords, while maintaining system security.
2) As a user, I must follow the password security rules set by the administrator to maintain the security of my account.
In this example, the consumer story depends on the administrator story. Store administrator is only tested for installation, cleaning and preservation of security policy, but not testable from the point of view of applying the policy to the end user. In addition, the implementation of the administrator's story does not put the product in a potentially deliverable form - and therefore does not carry an independent utility.
By revising user histories (and system architecture), we can remove dependencies by repartitioning in a different way - in our case, by the type of security policy and by putting together the policy setting and its application in each story:
1 ') As an administrator, I can set a password expiration period, so users will be required to periodically change passwords.
2 ') As an administrator, I can set the password complexity characteristics, so users will be required to create passwords that are difficult to select.
Now each story can exist by itself and can be implemented, tested and delivered quite independently.
Collapse
Unlike traditional requirements, user history is not an agreement on a specific functionality, but rather a container for such requirements, which have yet to be discussed, implemented, tested and accepted. This process of discussion between the business and the team adequately reflects the legitimacy and priority of information emanating from the business, but also predisposes to research through collaboration and feedback.
In our past companies with a vertical organization structure, written requirements generated a limited amount of communication between departments and served as a record of past agreements. Agile, on the contrary, is based on the idea that a team approach is more effective in solving problems in a dynamic environment (one team, in which both technical personnel and business represented by product manager are present, instead of cooperation between heterogeneous departments of the company, is the note of the author of the translation). User history is a structured real-time tool for the effective use of this effective direct communication and collaboration approach.
Finally, the debating of user stories allows teams to achieve predictability. The absence of overly restrictive and overly detailed requirements improves the ability of the team and business to find a compromise between the amount of functionality and the delivery date. Since each story allows some flexibility, the team also has more flexibility in meeting the goals of the release, which increases reliability and increases confidence.
Benefit
The goal of a flexible team is simple - to deliver the maximum benefit within available time and resources. Therefore, the use (sometimes we call it value - approx. Of the author of the translation ) is the most important attribute in the INVEST-model, and each user story should represent a certain value to the user, customer or stakeholder of the product. Priorities in backlogs are set based on the value of the story and the whole business is going through success or failing depending on the benefits that the team is able to deliver.
A typical challenge faced by teams is to learn how to write small, incremental user stories suitable for efficiently delivering value. Traditional approaches captured in us the algorithm of the functional breakdown of requirements into technical components. This “technical layering” approach in system design slows down delivery until all layers are joined together as a result of numerous iterations. Wake 9 (Wake) offers its vision of vertical rather than technical (horizontal) layering:
Imagine the whole story as a puff pastry, that is, the network layer, the data layer, the business logic layer and the user interface layer. With the (horizontal) separation of story, we serve only a slice of the pie. But we want to give the user the opportunity to feel the taste of the whole cake at once and the best way to achieve this is to cut vertically through the layers. Developers often have a tendency to work with only one layer at a time (and thus make it “correct”); However, a full-fledged level of data access (for example) has almost no value for the user if the system does not have a user interface.
Creating useful stories requires us to reorient our thinking through partitions from horizontal to vertical. We create user stories that “cut” the architecture through, so that we can provide value to the user and rely on his feedback as early and often as possible.
Although usually the value is focused on the user interacting with the system, sometimes the benefits are more naturally focused on the customer's representative or key stakeholder. For example, the director of marketing for an energy company asks for a higher conversion rate for banners on the site. Although the story can be recorded from the user's point of view:
As a user, I can see other tariff plans that more effectively attract my attention, so that I can subscribe to one of them, which is better suited to my lifestyle.
... however, in order to provide a clearer vision of real value, it would be more natural to write a story from the point of view of the marketing director:
As a marketing director, I can provide users with new tariff plans, so that they are more likely to continue to consume electricity from us.
Another difficulty that teams encounter is the justification for the benefits of technical storia such as refactoring, upgrading components, etc. For example, how to determine the value of a product such as:
To refactor the error logging system.
Formulating the value of a technical solution as a user story helps bring business to its business. For example:
As a consumer, I can get a complete and understandable error message anywhere in the product, so I will know what to do with the problem. OR
As a technical support engineer, I want the user to receive a full and understandable message everywhere within the application, so that he can deal with the problem without contacting technical support.
In these last examples, the value is evident both for the user, and for the product manager, and for the stakeholders, as well as for the team.
Susceptibility
A good user story is simulated. Although there can be any size in the backlog, in order for it to be implemented and tested in one iteration, the team must be able to provide a rough estimate of its complexity and the amount of work needed to complete it. The minimum investment in estimating a story is determining whether it will go into the framework of a single iteration. Additional accuracy in estimating will increase the team's predictability.
If the team is not able to evaluate the story, then the story is marked as too large or that it is not sufficiently defined. If it is too big for the evaluation, then it should be broken down into smaller stories. If the story is too weakly defined to be simulated, then a functional spike should be applied to reduce uncertainty, so that one or more user-assimilated user stories are obtained. (Each of these cases is discussed in detail in the following chapters).
One of the main advantages of estimating user stories is not only an idea of ​​the exact volume, but also the ability to isolate hidden assumptions, missing acceptance criteria and clarify the team view of storytelling. Thus, the dialogue accompanying the process of estimation is just as important, and perhaps more important, than the evaluation itself. The ability to assess a user story is highly dependent on its volume, as we will see below.
Compactness
User stories should be small enough to be executed in an iteration, otherwise they will not represent values ​​or will not be considered as completed at the end of the iteration. Although even more compact stor give more flexibility and productivity. There are two main reasons for this: increased throughput and reduced complexity.
Increase bandwidth
As is known from queuing theory, more compact packets pass through the system faster. This is one of the key principles of lean manufacturing and is reflected in Little's law (Little):
In a stable system (where bandwidth, i.e., the amount of work that can be done per unit of time, is constant), we must reduce the amount of current work, in order to reduce the cycle time (time interval between the beginning and end process). In our case, this means that fewer, more compact user stories will go through the development cycle faster .
Moreover, when the system is fully loaded, it can become unstable and the problem can become piled up. In heavily congested systems, large packets move through the system disproportionately slowly, as bandwidth drops. (Imagine a highway at rush hour. A motorcycle's chances of moving normally are much greater than those of cars and trucks — it is much easier to maneuver compact objects when driving in a loaded system.) Because development teams are usually almost full, or even higher ( 80-120%), they also fall into the "rush hour".
When the load reaches about 80% and more, more objects increase the cycle time (slow down) to a much greater degree than smaller objects. Moreover, the variation in the cycle time increases, that is, it becomes more difficult to predict when a packet can actually leave the system — an illustration of this is shown in Figure 1 below 10 . In turn, this low predictability destroys plans, commitments, and trust in the team.
Figure 1. Large packages have longer cycle times and higher variation.
Complexity reduction
More compact user stories go through the development process more quickly, not only because of their proportional volume, but also because of less complexity , and the complexity is non-linearly dependent on the volume . This is best seen in testing, where the extensiveness of the test system required to validate the functionality grows exponentially relative to the amount of the functionality itself. This corresponds to the recommendations for the development of clean code, namely, Robert Martin [Martin 2009] offers the following rules for the functions of the system:
This is one of the main reasons why the Fibonacci sequence (that is, 1, 2, 3, 5, 8, 13, 21, ...) is so effective in estimating user histories - the estimate of labor costs grows nonlinearly with increasing task volume.
On the ratio of volume and independence
The question of the relationship between volume and independence is quite legitimate, since it seems logical that less stori increase the number of dependencies. However, smaller stori, even with a slight increase in dependencies, deliver higher bandwidth and provide more operational feedback from the user than large user stories. Therefore, supporters of Agile always lean towards smaller stories, and then make them even smaller.
Testability
In full Agile, the entire code is tested , hence the testability of the story. If the story turns out to be untestable, then it is poorly formed, or unnecessarily complicated, or, perhaps, depends on other user stories in the backlog.
To make sure that the story does not get into the iteration, if they are not able to get out of it (that is, to be successfully tested), many flexible teams today use the approach: "first tests". This originates in XP communities that use Development Through Testing (TDD) - the practice of writing automated unit tests before writing code that must satisfy these tests.
Since then, this philosophy has been applied in developing the criterion for accepting storytelling and the necessary functional tests before coding itself. If the team knows how to test the story, then they probably also know how to implement it.
Due to testability, user stories fall into the same “pitfalls” as the requirements. Fuzzy words such as fast, manage, beautifully, cleanly , etc. are easy to write, but they are extremely difficult to test, because they mean different things to different people, and therefore should be avoided. And despite the fact that these words provide a certain level of talkability, restricting them with clear boundaries will help the team and business to synchronize the expectations of the result and avoid big surprises.
Literature
- Cohn, Mike. 2004. User Stories Applied: For Agile Software Development. Boston, MA: Addison-Wesley.
- Martin, Robert. 2009. Clean Code: A Handbook of Agile Software Craftsmanship. Boston: MA: Pearson Education.
- Poppendieck, Mary, and Tom Poppendieck. 2007. Implementing Lean Software Development: From Concept to Cash. Boston, MA: Addison-Wesley.
- Jeffries, Ron. 2001, August. Essential XP: Card, Conversation, and Con? Rmation. XP Magazine.
- 7 Bill Wake. www.XP123.com
8 Note by the author of the translation: for the purpose of practical compatibility of terminologies, I preferred the original abbreviation in English. language, refraining from wordplay and artificial constructions.
9 Ibid
10 Source: [Poppendieck 2007].
Source: https://habr.com/ru/post/84030/
All Articles