By: Ivsen Platcheck
September 11th,
2022
Introduction
I will start at the point of the process, when the Product Backlog items are known, at the current stage of the project, in order to be chosen for the next sprint. At this moment, it is not expected that all details have been defined, as they should be listed taking the OKRs Key-Results as inspiration source.
This text will not discuss all the process to reach this point. My goal here, is to talk about getting those raw defined Product Backlog items ready to be worked. The stories should have, been prioritized by the Product Owner, and the team should start working only on the top priority items at the next sprint.
In this text, I will talk about the process for getting the items ready to be worked by the team, at the next sprint. Grooming, or Refinement, and defining the tasks to be worked on, to reach the story goal is the goal at this point on the process. These meetings are not mandatory by the Scrum Guide, but in my experience, they make all the difference to reach success on achieving the objectives for the sprint cycle.
To help sort the tasks needed to achieve the goal for the Product Backlog item, in my work, I have used another tool I borrowed from UML definition. On a previous article [1], I talked about the Use Case artifact, to detail the tasks that should be taken to achieve the goals. And here I will show how I use it. This approach got me much more efficiency, quality, and accuracy through the process.
To make sure that the Product Backlog items eligible for the next sprint are ready to be worked on, it had been proposed a check point called Definition-of-Ready, or DoR, made by some statements defined by the Scrum Team. The DoR is also a non-official part of the Scrum, but are pretty useful, and helps to increase the overall efficiency.
At first, I am going to talk about the Definition-of-Ready, and then discuss the refinement processes.
I will not discuss about estimating the items’ sizes, here. This matter I will leave aside for bringing in another text.
The Definition-of-Ready Statement
It is the definition that a story, or Product Backlog item, is ready to be worked on. The Developer team is the responsible for dictating the requirements to make a story ready to be chosen for the next sprint.
To be set as ready, the story should be more detailed, most of the tasks must be defined. Taking a non-straight rule, but highly recommended, to be considered ready to be chosen, at the Sprint Planning meeting, and worked on, the story, or item, should have the business rules clear, fully detailed (even though, this can be changed along the sprint, if new learnings come, the stories can be estimated more accurately, the dependencies should be mapped, and lead to a testable value, at the increment generated.
Even though, the whole Scrum Team should be aware that more refinement can be demanded, along the sprint, as the process brings new learnings and requires adapting.
Some lights on Use Case
The process of refinement leads to break the stories into tasks. Those tasks are the way to achieve the story goal and create the increment. Those tasks should be enough to be completed in at most one sprint day. But that can be exceptions, for sure. Nothing is totally predictable, in Agile management.
This is the point where I use the UML Use Case artifact, as I wrote on my previous article [1]. The Use Case artifact will sort all the actions toward the fulfilling the goal, on executing the story. We can use it any levels needed to map all the tasks, functionalities, features, and possibilities.
Next, I am giving some lights on textual Use case definition. I will not go too deep, only some insights, before showing how I use them, to get the stories ready to be executes in the sprint. For further information, I suggest the book I put at the reference [5], which gives much more details on how to create the Use Cases for effectively help reaching the goals.
What is a Use Case?
Use case is and artifact defined by the UML language for Object Oriented Programming paradigm.
When using it as a tool for Agile approaches, I made some changes on the definition for how I use them. When we already have the OKRs initially defined, the use case describe the product/value behavior, under several conditions, taking as premises the Key-Results to be achieved.
The use case will help to define the tasks to be taken in order to reach the Key-Results goals. Use case, in this context, I use them purely textual, listing in a logical sequence all the tasks to be taken, with the Key-Results on mind.
The use case may have levels, which make it easier to analyze the tasks to be taken, at the minimum details. This process may use the knowledge of all involved people, like Organization Shareholders, High-ranked team, all the stakeholders, the team in charge of executing, and some clients, from high-level users till some initial-level users.
The goal is to break all the tasks in deep details, to avoid skip any feature that could impact on the quality or value delivery.
The use case must be objective and easy reading. It must leave no doubt for the executors, so they can create all the features to achieve the goal.
We can start with a very basic use case, defining the high-level tasks. Then, breaking those tasks, into smaller tasks, and the smaller task, into much smaller tasks, and so on, until reaching single tasks, which execution might take no more than a working day, in the sprint.
Fulfilling the definition foe Use case, the scope is the Product Backlog item, also known as the story. The process until reach this point of the process is not on the scope for this text. I assume that the Product Backlog has already been filled with the stories, by the Product Owner.
At this point, the items are already prioritized, and the top priority must be detailed and broken to the proper tasks, before the Sprint Planning event, when the Developers will choose the items to be executed along the next sprint, negotiating with the Product Owner, some demands from the stakeholders, and mediated by the Scrum Master.
I show, now, the usual structure I use to write my use cases. As I said, this is my way of doing it. There is no rule to tell which kind of use case is better, and the effect, certainly will be the same: definition of the tasks to be executed in the sprint, detailed close to their elemental tasks.
I developed this structure to fit my projects cycles, based on the examples from the reference [5], the Mr. Alistair Cockburn’s book”
| Scope: The story to be broken in tasks Level: The Use case can have different levels, according to the granularity (I will explain further) Context: If there is a special context that needs to be specified (Optional) Main Actor: Who is the clients (internal or external) for this story (optional) Stakeholders: (Optional) Dependencies: Dependencies from other stories when and if they exist, and how the may impact on the whole process. Definition of Ready: Checklist of conditions to define that the story is ready to be executed Actions to be taken: List of actions to fulfill the goal dictated by the story, in an ideal scenery Action stepAction step… Extensions or sidings: Exceptions, decisions to be taken, extended actions For action <n>, if the <Condition> meets do <Action>If not do <Action> When action <x> reach <Condition> do <Action> <List of possible decisions that might change the ideal scenery> Open Questions: Anything that needs special treatment |
Each action listed may be itself, another Item to be broken in tasks. This is what determines the level of the Use case. Each task that needs to be broken may be taken as a new story to break, or just a sort of tasks below it.
The way the team will deal with organizing the levels depends on the organization culture, or team agreement.
As more granularity the use case may deliver, better to make the tasks more visible and easy to understand and execute.
Most teams use to put the Extensions or siding mixed to the ideal scenery task list, defining the sidings directly on the task description.
Using use case, in my previous projects, I got to give the developers simple tasks to execute, and then increment, until reach the intended goal.
Refining the Product Backlog Items
Previously, I introduced a tool I use to help me refine the stories, when they are already listed as Product Backlog items. Now, I am presenting the refining process for being Chosen, at the Planning Session, at the next sprint
This process also known as Grooming takes commitment as refining the Backlog, and it is not a one-off task. Refining is a continuous practice that needs to be part of the development process.[7] Most use to make it on the planning meeting, or before this ceremony, but already in the sprint cycle itself.
I prefer to take this part of the process before the sprint, but this seems irrelevant for the final results. It’s up to the team to decide if they make this event part of the sprint or not.
Backlog grooming, or refinement, is a regulated process where Product Owners, with insights from the Scrum Master, the stakeholders, and at least some of the developers, review the high-prioritized items at the backlog, break them into tasks. Basic tasks that can be executed in one working day or less, delivers value to be incremented to the previously executed tasks.
Once the backlog is a dynamic artifact and it is being updated constantly on the scrum process, the refinement process must occur always before the next Sprint Planning.
Not only the tasks are defined, written, and committed. They are measured in terms of time, or effort. Estimated for allow the team to choose wisely the stories and tasks to be selectable to be included on the Sprint Backlog and go to execution at the next sprint.
This is how I use to turn the backlogs healthy and able to lead the team for a successful value delivery. Usually, a healthy backlog should have [8]:
- Contextual information and clear details to ease the team to understand the tasks to be executed.
- The estimates are made under the team-specific metrics, skills, capabilities
In this text I will not go into estimates techniques. The goal here is just tell about the refinement for the backlog items, before they go to be chosen for execution at the sprint.
References
[1] – Platcheck, Ivsen, “Doing the Right Thing to Start a New Project”, @yoelgrego.blog, June 30th, 2022.
[2] – “Definition of Ready”, KNOWLEDGEHUT SOLUTIONS PRIVATE LIMITED, 2022
[3] – “Gestão Ágil 2.0”, MindMaster, Maio de 2022.
[4] – “Gestão Ágil 2.0”, MindMaster, Junho de 2022.
[5] – COCKBURN, Alistair, “WRITING EFFECTIVE USE CASES”, Addison-Wesley, USA, 2001.
[6] – “Gestão Ágil2.0 – OKR – Módulo 4”, MindMaster, Junho de 2022.
[7] – WEISSANG, Emily, “Backlog Refinement (Backlog Grooming): How to Embed Best Practices”, Forecast Newsletter, December 14, 2021.
[8] – “THE ULTIMATE GUIDE TO JIRA BACKLOG GROOMING”, Ricksoft.