Get certified - Transform your world of work today


When a Task or Ticket Is Mature Enough to Leave the Backlog

10 April 2014

How do we know when a task/ticket is mature enough to leave the backlog and join the sprint backlog?

Every time I talk with product owners or people involved in the development cycle about why we groom the backlog, they always ask me, "What would be the outcome of doing a grooming?" And I tell them, "Mature tasks/tickets for the entire team to work with." But this seems to be confusing for them, since they don't know what a complete task looks like or what it should contain.

So after talking together, we came up with a checklist. I always use it when coaching teams with no experience with Scrum. (I know we could write an entire article about grooming, but here let's focus on the outcome of such meetings.)

For the team I was coaching, we come up with the following list -- and I want to say that it's just a guideline. You can use this list to check whether your task is ready, or you can edit it to fit your team's needs, or maybe you need something completely different for your Scrum practice.
  1. Title
  2. Description
  3. Documentation (if any/if needed)
  4. Mock-ups (if any/if needed)
  5. QA test cases
  6. Media needed for the task


You may think, "Nothing much to say here, just a clear title describing the task." For example:
  • Refund and return process
  • Return products and later refund in case the user has troubles
But what if you have a base code that ends in different sites or projects? The title is not the place to further explain the task/ticket. So, just keep it simple: Return process
A minute ago I said, "base code that ends in different sites or projects." In the team I was coaching they had that particularity, so we came up with the following template for titles:

Global/Project code - Title
Global - Return process, which meant applicable to all the projects
MX - Refund process, only applicable for Mexico


Here is where you write down what your task/ticket is all about, what you want the team to accomplish, and how you're going to be sure you know whether this task is done. But in order to fulfill that, you need the following:
  1. Background (epic only)
  2. User story
  3. Acceptance criteria
  4. Definition of Done
Background: We used the background as part of the description only when the task was an epic and would be broken down into smaller tasks/tickets. Let's use the following text as background for an epic:

Currently the refund and return process is a long process, started by the user in a phone call to our customer care area, and then in our back end we mostly handle it by macros and outside tools in order to store the information needed and finish the entire process.

Good enough for someone to understand why the owner of the task/ticket wrote it down in the first place, and it adds value to task/ticket itself.

However, a tip I'll give you is that the background needs to focus on one thing at a time. In the above text we see "the refund and return process." Even when both are related, the epic needs to handle them one at the time. So we changed the text:

Currently the return process is a long process started by the user by a phone call to our customer care area, and then in our back end we mostly handle it by macros and outside tools in order to store the information needed and finish the entire process.

Maybe you're thinking, "What happens with the other process?" Well, that other process would be another epic.

Now that the text is narrowed down to focus on one objective, we can continue to the next step.

User story: Everyone knows the user story template created by Mike Cohn: "As a [end-user role], I want [the desire] so that [the rationale]." Whoever is writing the task/ticket needs to write the user story using this template.

If the writer ends up with a general user story, one that can be broken down into small parts, tell them not to be afraid -- keep breaking it until the user story can't be broken down any further. That exercise will help them understand how big the task is.

Here is a case where an end user requests a task/ticket. The description you're about to read is the original description of the ticket:

Currently the refund and return process is a long process started by the user by a phone call to our customer care area, and then in our back end we mostly handle it by macros and outside tools in order to store the information needed and finish the entire process.

As you can see, the so-called "user story" was not close enough to a real and useful user story, so I explained the concept again and the next user story came up:

As a customer with a faulty product, I want to return the product so that I can get the correct one.

This was still way too generic, so we rewrote it again:

As a customer with a faulty product, I want to click on the "return product" button so that I can start the return process and get information on how to do so.

There was enough information this time, neither too broad nor too detailed -- exactly what we needed. But the owner of the ticket/task was afraid that the reader of the ticket wouldn't get the full idea. That's when we added we added acceptance criteria and the Definition of Done.

Acceptance criteria: We defined it as what the PO needs from this task/ticket for it to be accepted, what rules or key features we need covered by the task/ticket.

In the example we have the following:
  • Display the return button next to the items that can be returned.
  • Display it only when the order has been delivered completely.
  • Generate confirmation once the button is clicked.
  • Generate a notification that the return process for the selected product is in progress.
  • Give visual notification that the product is in the return process.
All the criteria listed above can be complemented using the mock-ups section. Make sure to list everything that is needed to set the base for the task in question, to start or control it.

Once you have all that covered, it's time to limit the scope of the task/ticket and know when we can close it and therefore reach done status.

Definition of Done: If we don't set up an objective or objectives, the task/ticket will be open forever. When will it really be done? When the task/ticket passes all the quality tests necessary by the PO, team, or even company standards; but you have to be clear which ones or, if it's something new, define and list them.
  • Regression tests
  • Usability tests
  • Confirmation from the warehouse when they get notification of a return process
  • UI tests
Once we have verified that everything is in place, we can deliver this ticket to staging and then to the live environment.


Here is the place where you share information from third parties or other departments that would help the development of the current task/ticket or help the developers understand what to deliver. It should be as specific as necessary, since it will contain all the details required to fulfill the task. In the case we are following, we attached:
  • Input needed by the warehouse system to start a return process (a simple text explaining each variable and content needed)
  • Texts used for notifications and messages


In case the task/ticket needs design mock-ups, you need to provide them for the following purposes:
  1. Exemplify the expected results
  2. UIX changes
In the case of UIX improvements or changes, make sure they are approved by all members involved before sending the ticket to the sprint backlog.

QA test cases

This is the most important part of the task/ticket, since most of these test cases can be made out of the user stories or acceptance criteria. The test cases are different from the Definition of Done because they could be new test cases for the improvement or bug-related to the task/ticket.

Since we are just talking about part of a task/ticket, we won't give examples, because every team or company can have different templates for their test cases.


Any image related to the mock-ups section or documentation needs to be provided in this area. Any short explanation is good if not provided in the above areas.

I hope that this list is good enough for your Scrum practice, and that it can help you get better tasks/tickets out of your grooming meetings. That way you'll provide good tasks/tickets to your development team.

The author thanks Edgardo Dominguez for his review of this piece.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4.8 (4 ratings)


Tim Baffa, CSM, 4/11/2014 2:48:40 PM
Good points and structure for driving a "Definition of Ready" for inclusion into Sprint Backlogs. Many times, imperfect items are introduced into sprints, and teams simply are not able to get to their definition of "done".

I would only add 2 items to this outline:

1) The estimate in story points, and once offered in Sprint Planning Part 1 by the PO, the time unit estimates for the tasks needed for that sprint item to weigh against team velocity and capacity for the upcoming sprint.

2) A draft of the examples (see "Specification By Example) for the sprint item that can be used for communication and dissemination of the functionality to be developed, as well as driving TDD aspects of the development and testing process.
Javier Gloria, CSM, 2/10/2015 10:27:41 PM
thanks and sorry for the late response will update the article

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up