October 18, 2021


News for Agilists

The 7 steps guide to create your first Scrum Backlog | by Anca Onuta | Serious Scrum | Jan, 2021

Half a baked cake may not be enough to feed a wedding party, but it’s enough to taste and leave everyone looking forward to the rest of the cake. — Jeff Patton in User Story Mapping: Discover the Whole Story, Build the Right Product.

It might be hard to get started with your first Agile Backlog, and here’s what you need to know:

  • In Agile, it is vital to get started.
  • Any step is better than nothing.
  • You can change direction and adapt at any point.
  • Take tough decisions as late as possible.
  • Preserve options. As we don’t know everything from the beginning, we don’t want to lock ourselves into bad choices early.

The Product Owner. It would be best if you had someone who’s got the vision, knows the customer, and has a great understanding of the product. As the team gets more experienced with Agile, they will learn how to structure it.

Step 1: Define your customer

The customer is the one who pays your salary. The customer is also the one who uses the deliverables produced by the Agile team. The 2 might be contradicting sometimes. My strong advice is to keep it simple, don’t over think it. As an Agile team, your goal is to keep your customer satisfied by delivering meaningful functionalities. Identify who is the person that represents the voice of the customer and ensure that in the eyes of this person, what you deliver bring him/her value.

Step 2: Define your product vision

If you have a physical product or software, it will be easier to identify it. A product can be a service, process, or merely a problem that you want to solve.

  • Minimize human error during the accounting process.

Step 3: Define the solution

If you have a product, you want to define the functionalities that you aim to develop next.

  • launch the community program
  • implement automatic data validations

Step 4: Prioritise the functionalities from a business value perspective

Knowing your customer is significant for this step. There are two opinions on how to prioritize the functionalities:

  1. to ask the customer.
  • functionalities that you Should do
  • functionalities that you Could do
  • Functionalities that you Won’t do

Step 5: Define the deliverables for the top functionality

Now it’s time to get into the details. Suppose you are recently getting started with Agile. In that case, I recommend you make a list of all the deliverables for the topmost necessary functionality on your list.

  • new data gathering process description
  • data gathering checklist
  • Training on how to gather data

In Agile, we build the Backlog incrementally.

You define ONLY the requirements that you know at this moment.

  • you haven’t taken the tough decisions yet
  • priorities can always change
  • you build incrementally
  • you don’t want to waste time in defining requirements that will change
  • it’s up to the team to decide how to implement the deliverables

Step 6: Rewrite the deliverables as stories

The chances are that you heard of user stories before.

Shared documents aren’t shared understanding.

— Jeff Patton in User Story Mapping: Discover the Whole Story, Build the Right Product.

Deliverables are an excellent way to measure progress. However, the user stories help the Agile team to understand and deliver business value to the customers. Remember step 1:

As an Agile team, your goal is to keep your customer satisfied by delivering meaningful functionalities.

Sometimes the definitions of the stories sound like rocket science, but they aren’t.

Here’s how you define your stories:

When using each deliverable from the list above, ideally your customer is able to say: As <customer> I <action> for the benefit of <purpose>.

  • <action> — replace it with how the customer will use the deliverable.
  • <purpose> — describe how the deliverable will help the customer
  • As Tesla Marketing Director (Mike), I want to decide the marketing budget for the new Model Y for the benefit of launching the new pre-sales campaign.
  • You would have thought an accountant would use such a report, right? Knowing how your customer will use the information might give you hints providing a higher level and more explanations on the financial terms. Mike could be a satisfied customer.
  • If the finance director or audit department would use this report, the Agile team might structure it differently.
  • new data gathering process description will become:
  • As the Recruitment Manager, I want to define the data gathering team’s job description to be recruited in time to launch the new process.

What if?

While you do this exercise, you might realize that multiple customers will use some deliverables. They should be suitable for various audiences.

Step 7: Decide what story to deliver first

Earlier you ordered the functionalities by business value. At this step, you’ll prioritize the stories (multiple stories define functionality). Ordering the stories is a tricky step. Now it’s time to remember who the customer is and the functionality you decided to deliver first.

What if?

Are my stories dependent on one another?

Do you want to write for Serious Scrum or seriously discuss Scrum?

Source link