Using these techniques, teams can ensure that the sprint backlog is well-defined and prioritized, which can help to improve the quality and efficiency of the development process.

  1. User story mapping: This technique helps to visualize the user’s journey through the product, which can then be used to identify the most important features to add to the backlog. It can also help to identify dependencies and gaps in the product’s functionality.

  2. Relative sizing: This technique involves estimating the size of the user stories relative to one another, rather than assigning specific time estimates. This can help to prioritize the backlog based on the relative importance of each story.

  3. Definition of ready (DoR): DoR is a set of criteria that must be met before a user story can be added to the sprint backlog. This helps to ensure that the story is well-defined and ready to be worked on during the sprint.

  4. Acceptance criteria: Defining acceptance criteria for each user story helps to ensure that the team has a clear understanding of what needs to be done to complete the story. This can help to avoid misunderstandings and ensure that the story meets the needs of the stakeholders.

  5. Refinement meetings: Regular refinement meetings can help the team to review the backlog and ensure that it is up-to-date and prioritized correctly. These meetings can also help to identify any new user stories that need to be added to the backlog.

  6. Spike sessions: Sometimes, there may be technical or design issues that need to be resolved before a user story can be worked on. Spike sessions can be used to explore these issues and come up with a plan to address them.

  7. Story splitting: Large user stories can be difficult to estimate and work on. Story splitting involves breaking down large user stories into smaller, more manageable pieces. This can help to make the user stories more manageable and easier to work on.

User story mapping use case example

Here’s an example of how it might be used to refine the backlog for a use case about spatial analysis for opening a new store in a city:

Start with the goal: The goal of this use case is to identify the best location for a new store in a city, based on spatial analysis.

Identify user roles: There are several user roles involved in this use case, including the store manager, the real estate team, and the data analyst.

Identify high-level user stories: High-level user stories might include things like “As a store manager, I want to be able to see a map of the city with potential locations for a new store highlighted, so that I can make an informed decision about where to open the store.”

Break down user stories: The high-level user stories can then be broken down into smaller user stories, such as “As a store manager, I want to be able to filter potential locations based on factors like population density and income, so that I can narrow down the options.” Other user stories might include things like “As a data analyst, I want to be able to visualize demographic data for different areas of the city, so that I can identify potential target markets.”

Order user stories by priority: Once the user stories have been broken down, they can be ordered by priority. For example, the user story about filtering potential locations might be higher priority than the user story about visualizing demographic data.

Identify dependencies: It’s important to identify any dependencies between user stories. For example, the user story about visualizing demographic data might depend on the user story about filtering potential locations.

Refine user stories: The user stories can then be refined further, by adding acceptance criteria and defining what “done” looks like for each user story.

Using this approach, the team can create a detailed backlog that reflects the needs of the different user roles involved in the use case, and can prioritize the user stories based on their importance and dependencies. This can help to ensure that the team is working on the most important user stories first, and can deliver value to the stakeholders more quickly.

Relative sizing use case example

User story: As a business owner, I want to perform spatial analysis to identify potential locations for a new store in the city.

Estimate the size of the user story relative to other user stories in the backlog. For example, let’s say that another user story is “As a customer, I want to be able to search for products by category on the company website”. If the team feels that this user story is smaller and less complex than the spatial analysis user story, they could assign it a lower relative size (e.g. 3 points), while assigning the spatial analysis user story a higher relative size (e.g. 8 points).

Based on the estimated relative sizes, prioritize the user stories in the backlog. The team could decide that the spatial analysis user story is a higher priority than the product search user story, since it has a higher relative size.

During sprint planning, use the estimated relative sizes to determine how many user stories can be completed in the sprint. For example, if the team has decided that the spatial analysis user story is an 8-point story and they have a capacity of 20 points for the sprint, they could decide to take on two other smaller user stories (e.g. 3 points each) to fill out the remaining capacity.

By using relative sizing, the team can more easily prioritize and estimate the user stories in the backlog, which can help to ensure that the most important and complex user stories are addressed first.

Definition of ready use case example

Use case: Spatial analysis for opening a new store in a city

User Story: The user story should be well-defined and written in a way that clearly communicates the need for the spatial analysis for opening a new store in a city.

Acceptance Criteria: The acceptance criteria should be clearly defined and communicated to the team. It should include:

  • The specific geographic area to be analyzed, including any boundaries or limitations.
  • The types of data to be used for the analysis, such as population demographics, traffic patterns, and competition.
  • The specific goals and objectives of the analysis, such as identifying the best location for a new store based on foot traffic and proximity to other businesses.
  • Any constraints or limitations on the analysis, such as budget or time constraints.

Dependencies: Any dependencies or requirements for completing the analysis should be identified and communicated to the team, such as access to specific data sources or software tools.

Resources: The necessary resources for completing the analysis, such as data sets, software tools, or expertise, should be identified and made available to the team.

Estimates: The team should have a clear understanding of the scope and complexity of the analysis, and should be able to provide accurate estimates of the time and effort required to complete it.

Risks: Any potential risks or challenges associated with the analysis should be identified and discussed with the team, and plans should be made to mitigate or address them.

By ensuring that these criteria are met before starting work on the use case, the team can ensure that they have a clear understanding of what needs to be done and that they have the necessary resources and support to do it effectively.