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:
- It is okay if we don’t know everything from the beginning.
- 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.
A customer can be internal — colleagues, other departments, or external — a paying client.
If you have multiple customers, you may want to prioritize them. Clarifying the order of requirements based on customers will save you many hassles during the execution phase.
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.
To give you some specific examples of product vision:
- Make daily meetings obsolete.
- 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.
Examples of functionalities for make daily meetings obsolete:
- automatic suggestion of the daily report
- launch the community program
Suppose your product is instead a service, process improvement, or solving a specific problem. In that case, you’ll define how you will resolve the issue.
- replace manual data collection with a scan tool
- implement automatic data validations
At this stage, you will list your top 3–5 functionalities as a bullet point list. You’ll make an exhaustive list later on. You can start with 1–2 functionalities that are known at the present moment and add more iteratively.
Remember: in Agile, your goal is to get started and keep things rolling, not to have the complete system from the beginning.
It is essential to think about these functionalities as independent functionalities. If you cannot make them self-contained by any means, they are probably waterfall deliverable steps and not functionalities. Do not go to the next step until you have defined independent functionalities at this step. That’s key to the success of your Agile implementation.
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:
- the Product Owner is a strong visionary and decides what is best for the customer
- to ask the customer.
You need to know that priorities can always change, which means you need an easy decision to start today. You can postpone the tough decisions for later.
Now you’ll order your functionalities as an ordered list. You can go an extra step and use the MoSCoW prioritization method in which you define the:
- Functionalities that you MUST do
- functionalities that you Should do
- functionalities that you Could do
- Functionalities that you Won’t do
Learn more about the MoSCoW prioritization method in Agile:
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.
A deliverable is a concrete output of the Agile teamwork. But on the other hand, they do not explain the technical solution implemented — the “how”. The way the deliverable will be implemented will be up to the team.
The deliverables must be independent of each other.
- a report with the profit and losses of Tesla account for December 2020.
- new data gathering process description
- data gathering checklist
- Training on how to gather data
Be as detailed and specific as possible. This list will be the measurement of success.
As you do this step, you might feel the need to jump between multiple functionalities. Hold on! Take ONLY the functionality from the top of the list — with the highest priority.
In Agile, we build the Backlog incrementally.
You define ONLY the requirements that you know at this moment.
- you don’t know it all from the beginning
- 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.
WHY? Aren’t deliverables good enough?
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>.
- <customer> — the customer role who will use the deliverable. For a better understanding of the story, don’t be afraid to write specific people’s names. When doing it, the Agile team connects more with the customer.
- <action> — replace it with how the customer will use the deliverable.
- <purpose> — describe how the deliverable will help the customer
- a report with the profit and losses of Tesla account for December 2020, will become:
- 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.
While you do this exercise, you might realize that multiple customers will use some deliverables. They should be suitable for various audiences.
In Agile, we build incrementally. Now you serve a specific customer on certain functionalities. Later on, you’ll update the functionalities to help other customers. That’s perfectly fine.
What if you identify new customers/functionalities/deliverables?
There will always be more things to do. If you don’t want to forget your ideas, add them at the bottom of your Backlog and move on.
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.
Look at the Backlog and pick the user stories.
Are my stories dependent on one another?
If your user stories have a chronological time of events, provide the new process draft and the final version. Then it is okay. The draft version will be on top of the Backlog, and the final version will be lower on the Backlog.
In conclusion, while building your first Agile Backlog, your mission is to get the first version out! It’s not going to be perfect, but it will be useful.