When we design a new product, or when we think of a problem to be solved, we are faced with different levels of knowledge about the various aspects to be addressed. Certainly, some characteristics that we wish for the product we know well and we manage to detail. Other, we have only one idea, a high-level vision of what we want. Also, it does not make much sense to define a product with a huge amount of stories, or Backlog Items (PBI – Product Backlog Item). It gets confusing and hard to explain to anyone. So it is only natural that we initially design our Product Backlog with higher level items, which will later be detailed / refined to allow the team to work on Sprint.
We often call these high-level Epic items. They are stories that give an overview of the intended, but are still very large, in the sense that they require a lot of time for their accomplishment, and have few details, not having all the information necessary for the team to carry them out. A simple example of such a story would be The Director wants to control the stock to optimize the use of financial resources. This story is easy to understand when presenting the new product, however it will require much more than a Sprint to be completed and does not have enough details to be implemented by the team.
Epics need to be detailed for the purpose of allowing the team to work. In general, there is no concern to work as in structured analysis, guarding the epic and successively blowing up its by-products. What we do in practice is to divide the epic into smaller stories that cover all that is desired in the epic, and can then discard it.
Then there is more than normal doubt: What level of detail is ideal? What granularity do we seek? To answer this we use an acronym proposed by William Wake, INVEST – Independent, Negotiable, Valuable, Estimable, Small and Testable. Let’s look briefly at each of these characteristics.
Ideally, we can work on a story that is independent of the rest. So we can work on it at any time, without depending on others. This is not always possible, but it must be sought. That is, we try to minimize dependencies.
A story must be able to be worked together by the client and the team. Thus, the concept must be well defined and the details are later resolved together. The essence must be captured, leaving the details as part of the implementation.
A story has to provide value to the customer. When dividing stories we should be concerned about maintaining the full vision of its implementation so that the client realizes its value and supports the development of the story. We have so-called “technical” stories where the customer often has difficulty in seeing value, but we’ll talk about it another time. Generally speaking, we must avoid them, trying to insert them as parts of other stories where the customer perceives value. This is not always possible.
In order for the team to be able to schedule their work and the client can prioritize the stories, they must be estimated. The bigger the story, the more imprecise and difficult it is to estimate.
Stories must be small. They should be able to be done with few man-hours, a few days of work only. In addition, small ones are estimated more easily and with greater accuracy.
Everything done by the team must be verified and validated. A good exercise is to set the test before working on the story. If it is difficult to define tests, the story may not have been well understood or be at the level of incorrect abstraction.
It is critical for everyone in the Scrum team to understand that the work is done by stories and therefore the quality of the work will define the effectiveness and efficiency of the team. Still, the work in defining the stories, the necessary discussions and surveys, and other related activities, serve for the acquisition of knowledge by the team, and even by the client.
Returning to our simple initial example, we could replace our epic The Director wants to control the stock to optimize the use of financial resources by:
Director wants to register the goods receipt to allow sales and limit the use of the warehouse
Seller needs to post goods issue to allow stock replenishment
Controller wants to check and adjust the quantity of the existing merchandise to make material balance
Smaller stories, which cover the initial need presented in the epic, and allow and guide the work of the team. With such stories, given INVEST, it will be easier to estimate.
Can you share your stories in this way? What is your greatest difficulty? Tell us. Maybe we did not think of something together …
In the next posts of the series we will talk more about estimates, characteristics / types of histories, and other more advanced subjects.
Keep following us. See you soon and good Scrum!