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 populate our Product Backlog with higher level items, which will later be detailed / refined to allow Sprint team work.

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 complete 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.

Independent

The ideal is that 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 the dependences.

Negociável

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.

Valuable

A story has to provide value to the client. 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.

Estimable

For the team can program their work and the client can prioritize the stories, they must be estimated. The larger the story, the more imprecise and difficult it is to estimate. Small stories should be small. They should be able to be done with few man-hours, a few days of work only. Additionally, small ones are estimated more easily and with greater precision.

Testables

Everything that is done by the team must be able to be verified and validated. A good exercise is to set the test before working on the story. If it is difficult to set tests, the story may not have been well understood or be at the wrong abstraction level.

It is fundamental for everyone in the Scrum team to understand that the work is done by stories and therefore the quality of the stories will define the effectiveness and the 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 must register the goods issue to allow stock replacement
  • Controller wants to check and adjust the quantity of existing merchandise to make the 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, following INVEST, it will be easier to estimate.

On ScrumHalf  you can classify stories as Epics. Can you work your stories this way? What is your greatest difficulty? Tell us. Maybe we will not think of something together …

In the next posts of the series we will talk more about estimates, characteristics / types of stories, and other more advanced subjects. Keep following us. See you soon and good Scrum!