User Stories – are a matter of doubt for many beginners, and sometimes even for practitioners with some experience. This is even proven by the statistics of our Blog (with more than 10 thousand readers / month), which shows that posts about User Stories are always among the most wanted. So, let’s try to see Stories in a practical and simple way. This series of posts is dedicated to this.
A Scrum project has its requirements organized into a list called Product Backlog. Thus, roughly, the requirements of a project or product are items in this list, or rather Backlog items. The most commonly used way to describe
these items are User Stories, which we will call here only Stories.
A Story can be written as follows (Cohn, 2004):
- An Actor wants Something for a Reason.
- The Actor is the representation of a user role, that is, of a type of user, such as Secretary, Athlete, Client, Associate, Director, etc.
Something is the user’s goal when using the product being created. It makes clear what the user expects when using the product. Something like “issuing a sales report” or “checking your heart rate.” - The Reason works as a justification and helps the Scrum Team to understand the Story and the need of the Actor. “To reward the best seller” and “to adjust the intensity of the exercise” are examples of reasons.
This format makes clear the idea of History: communicate to the Team a “requirement”, that is, something that needs to be done during the development of the product or project. Thus, the team should read the story and understand what should be done, eventually clarifying any doubts with the PO.
But is only such a description sufficient?
Not always. Depending on the type of product / project being conducted, the “intimacy” and team time with it, a single sentence may be enough. But most of the time this is not true.
How to do it then?
Scrum also has a solution to this: Definition of Ready – Definition of Ready.
It is considered that a story is prepared when it has already been refined and detailed enough that the Team can work on it. Considering that the Development Team itself should estimate and meet the prescribed by history, nothing more just than the definition of what a story should present to be worked out is defined by the Development Team with the PO. This is exactly the Ready Set – a combination between PO and Development Team about what is needed for a story to be considered prepared and therefore be able to be worked on in a Sprint. This definition promotes transparency, making it clear to the entire Scrum Team what is needed in terms of preparation and aligning the expectations of the Development Team and the PO.
While some teams use a very simple Prepared Definition, others include several items:
- Necessary artifacts such as Chaos Use Models and Business Models, Fabric Sketches, Models, etc .;
- Characteristics of the story, as well-defined aggregate value;
- Criteria for acceptance; and
- Capacity of the team, as the team have the appropriate professionals to carry out the story, etc.
All this according to the type of project being developed and with the characteristics of Time.
In conclusion, the stories mark all the work being done on the project, and are simply the expression of what users of the product want, that allows Time to develop the right product.
But what kinds of stories are there? How to define optimal granularity? Can you estimate? These and other issues will be addressed in the next posts.
Oh, and do not forget to comment with your doubts. If we do not address it throughout the series, we will deal with it in the end.
Good Scrum!
