Having well-defined epics and user stories in place is a great way to prepare for upcoming projects. However, that’s just the first step. The second step is to examine your goals and what you want to achieve with the whole team. You can break things down from there. This mainly happens during, before, or after a backlog grooming.

I want to share how my current team and I decided to plan features/projects etc., which will give you insight into how we further structure our backlog as well as our implicit working agreements as a team/squad.

There are a couple of reasons why we do this:

1. We as a squad believe that good planning and preparation will save time later on
2. A clean backlog will help us to stay focused on a project, and its priorities
3. Visibility and clarity help us to be transparent about our progress and the next steps

Do I need to mention that good planning and execution reduce working hours, and stress, and increase mood, plus work quality? 🤔

In all the companies I worked for, the Product and Engineering Teams were constantly confronted with changing requirements, tech debt, and deadlines. I regularly received questions and requests from stakeholders or customers like:

• When will it be finished?
• How will it look?
• Can we check it already?
• Can you change XYZ?
• Why does it take so long?
• etc...

While exhausting and challenging, on the typical day of a Product Manager, I always remind myself of the following:

I am responsible for answering these questions! 💪

Not only for the stakeholders or the team but also for myself. Why? Because that’s the only way to stay on top of what’s happening. A couple of times, I caught myself getting annoyed or angry at these questions. Looking back, I realized the only reason for this reaction was that I didn’t have the answers. That’s why I always try to know the answer before someone asks.

I believe that good product people are always one step ahead 👣

‍

Adding Additional Ticket Types to Your Backlog

The user story represents a collection of requirements that are detailed enough for Software Engineers to implement. Sometimes stories have bigger scopes, more complexity, or need research before they can be developed. In this case, we break them down/add additional issue types.

‍

💡 Spikes to Lighten Up Your Backlog

To me, a spike is one of the most important and underestimated tasks.

We use spikes to investigate deeper into a certain topic or to do research in a defined time box. The idea behind this is to figure out how to organize and break down work, identify risks, or evaluate/plan technical approaches.

Instead of INVEST, we use the SMART framework for spikes and tasks:

• Specific
• Measurable
• Achievable
• Relevant
• Time-boxed

You can write a spike similar to a user story. Instead of acceptance criteria, we define the expected outcomes.

Simple Example:

Let’s imagine we want to sell T-shirts online with our own online store. We’ve built our own online shop, and are close to launching it. One missing piece in the puzzle is a purchase history that shows the customer history of the products they’ve bought, including payment information, billing, shipping address, etc.

Since our team hasn’t done anything like this before, we need to come up with a technical concept (imagine the UI exists already). When we set the scope of a spike we focus on the number of Developers involved and the days they’ll spend on the topic. We aim for max. 3 days. In our case, the Engineers prefer to write the tasks because they know what the outcome should be best.

‍

Intro:

In order to be able to provide a purchase history to our customers, we need to build a service that collects data from other services like:

sales_service

product_service

invoicing_service

shipping_service

etc...

‍

Expected outcomes:

• Check the design and understand the requirements for all information that needs to be shown
  • Read the documentation of the listed services
  • Reach out to the code owners of other squads to understand dependencies
• Provide a proof of concept for service architecture
• Everything has to be documented in Confluence and shared with the squad and stakeholders

‍

Notes:

…

‍

Open Questions:

…

‍

Timebox: 1 developer, 2 days

‍

🛠 Tasks to Get the Little Things Done

A task’s scope is smaller than that of a story. At the same time, they don’t necessarily need to deliver any end-to-end (E2E) customer value. We define tasks as work that can be done within 1-2 days.

Example:
Updating database services from Java 10 to Java 11.0.2

Tasks can be estimated or time-boxed depending on how you as a team like to deal with them. We write tasks in the same way as user stories.

‍

👨‍🔧 Tech Stories for Your Engineers

We apply tech stories for two use cases:

1. Enabling user stories if the scope is bigger and requires a technical foundation.
2. For bigger technical tasks that don’t necessarily deliver customer value but are important to keep the system running.

‍

Initial user story:
Enable our customers to access a purchase history on their user profile

In this case, the new page would require a backend service that provides this kind of information. In this example, building the new backend service is a very big task with cross-team dependencies. Therefore, it makes sense to break it down into a tech story.

‍

Intro:

…

‍

Acceptance Criteria:

• The new service has been written in Java
• All tests pass after the update
  • No regressions
• Everything runs on the new version

‍

Notes:

…

‍

Open Questions:

...

‍

If you're looking for a comprehensive guide to better manage your backlog, check out 👉 this read 📝

‍

🐞 Bugs (Internal & External)

Let’s start with a funny quote from one of the best Engineers I worked with:

“We try to implement it perfectly and introduce bugs later, but this does not work always.” - Mouad Benchchaoui

Sometimes (😉) software contains smaller or bigger errors called bugs. It’s essential to track and prioritize them based on their impact, costs, urgency, etc. We deal with separate bugs in two different categories:

1. Internal bugs (found by ourselves during development or testing)
2. External bugs (reported by customers, partners, or other parties)

‍

We use the ticket type “Bug” for internal bugs and “Production Support” for external bugs. The reason we use two different types of tickets is to better separate and filter them in the backlogs. Another benefit is that you can better track and report on things we’ve found vs. our customers. That helps us to improve our processes in the event we find bugs after launching, which should have happened before.

The most important information we track in our bug tickets is:

‍

Title:

As for all other tickets, we try to define titles with as much detail as possible. On top of that, we add the environment which can be, for example, “Production” (live system) or “Staging” (testing environment).

Bad example: Login fails

Better example: [Production]: Users can’t log in on our web dashboard

‍

Application type & affected version:

In order to help Quality Assurers or Engineers to investigate issues fast, it’s important to provide as much information as possible.

Application: Web dashboard www.domainname.com & iOS app

Affected version: Google Chrome 77.0.3865.90, iOS 13.1.1 (Note: older versions are affected as well)

‍

Steps to reproduce: (if possible)

To better understand the problem and debug it, we add the individual steps to reproduce the failed login:

1. Visit www.domainname.com/login

2. Insert a valid username and password

3. Press the login button

4. Error message modal appears: “Can’t log in 500 fatal error.” See added screenshot

‍

Expected outcomes:

In the case of the login, the expected outcome would’ve been a successful login and redirection to www.domainname.com

If Customer Support is trained to gather this information from a conversation, we gain even more insights. Sometimes customers expect different outcomes that help to improve the product and user experience.

After breaking down our features and projects into smaller and more granular pieces, there’s one final and important task for us to do...

‍

Linking Tickets in Your Backlog

To keep our backlog “clean” we link to all tickets in two ways

1. All tickets that are related to the project will be linked to the epic/feature
2. Tickets that have a dependency on each other like tech and user stories

The biggest mistake most Product Managers and teams make is linking tickets that are out of scope. Whenever you’ve decided to build a feature and its scope, you should link everything to it. A lot of teams link future requests, stories, or work that pops up after launch to it. This leads to the problem of the epic’s scope blowing up and you can’t keep track of the progress because it gets bigger and bigger. I recommend creating follow-up epics. You can use them to link to all tickets which are beyond the MVP or MMF. This only works if your feature has a clear scope.

Does it? 😉

‍

One More Backlog Thing!

A clear and clean breakdown will help you to get started from day one in a structured way. I still remind myself every day about the importance of clean tickets. That means making sure that every single ticket has a clear title, a clear description, and most importantly:

Clear acceptance criteria or goals & outcomes 🚀🏁🏆

I frequently see teams whose backlogs or tickets in active development don’t have any content besides a title. This leads to the following problematic questions:

• What needs to be accepted by the Product Manager or Designer?
• What to look at when code review happens?
• How does someone know what to test?
• What is the scope and when’s it done?

That’s why having a “definition of ready” and a “definition of done” is so important for teams.
You can read more about that here: 👉 Definition of done & ready

I’d love to hear how you break down your features. Tell me on Linkedin.