If you’ve been hitchhiking around the galaxy of agility at enterprise scale, you may already be familiar with this guide. Which means that you might be aware of where you are in this intergalactic journey of ours. If you aren’t, don’t panic. Here you are:
You are most likely a product owner in charge of a team that is part of a much larger initiative to deliver an enterprise-grade product. And, if you followed chapter one of this guide, then by now:
- You know your users pretty well. You used impact mapping to map out their business goals into the application’s user needs, and from there, you will derive your entire product backlog.
- You have learned a great deal about your user’s day-to-day business by drilling down into each user need together in an engaged and collaborative way, using business analysis techniques.
- You have a pretty good idea about how to break down work in user stories and how to implement each user need because you used user story mapping!
If you have achieved all the above, pat yourself on the back. You are already one heck of a product owner, and I’m sure that by now, you are eager to start a new adventure, like writing your enterprise-grade backlog.
The thing is, in most guides, this would be the part where someone would explain to you how to properly write user stories. But you see, I don’t feel like talking about this again! There’s a galaxy of great literature already out there on proper user story writing, which, unfortunately, many still disregard.
So instead, I’m going to talk about the consequences; how you can seriously crash and burn by overlooking something as seemingly harmless as your product backlog. You can be sure, overlooking your backlog is way worse than engaging hyperspace speed without permission, so I hope that this topic finally grabs your attention! With that said, grab your towel and let’s go.
CHAPTER 2 - The Rules of the Guide on Product Backlog Writing
Remember garbage in, garbage out? When it comes to your backlog, and the performance and quality of your team’s deliverables, this is precisely how it works! The backlog aspect is especially critical if you are implementing low-code technology as we are in this case; it gets consumed about twice as fast. So, without a well-defined backlog, you will block your team double! And you don’t want to do that, so how can you avoid this?
Step 4: Small Yet Valuable
Let’s go back in time. Remember when thought you had written your best user story ever? You really took your time with that one, thought it through, let it mature, and considered all possible angles. “What a great piece of requirements engineering,” you must have thought. Almost as if it was the answer to life, the universe, and everything.
But sadly when you tried to refine this piece of work with your team, it was as if a Vogon was reciting poetry to them!
After an agitated refinement session, you finally got the user story through, just to be picked up by one of the developers. Wasn’t it weird how that developer seemed generally overstressed, spent long hours in the office, and when the sprint ended, they only developed about a tenth of that user story?
What’s the problem here? Actually, there’s a considerable number of things going wrong in this situation, but it all derives from the fact that you asked your developer to implement an epic instead of a user story.
User stories must be as small (yet meaningful) as humanly possible. “But why?” you might ask. Here are a few reasons:
- To make them more tangible for effort estimation
- To reduce the probability of unhidden scope
- To make impact analysis easier and more contained
- To ultimately deliver them as early as possible within the sprint to gather feedback.
So how should you start writing user stories? Think:
- Lazy: write just enough that seems to work then stop and take it to your team so that you may collaboratively refine it together.
- Demo: ask yourself if this user story is something you’d still be happy to show at the sprint demo to your audience. Is it meaningful or valuable enough?
Step 5: Make it Personal
Planet Earth’s Motorola, Kodak, BlockBuster, and hi5—this list could be longer—are all crystal clear examples of what can happen to a well established and successful company should it stop listening to their customers, or better said, their end users. In fact, I should really change “listen” to “obsess!”
Some time ago, I read a piece on how Atlassian determined what to put in their backlog. The speaker shared that at one of their offices, they had put up persona cards on the bathroom walls so that Atlassians don’t risk a minute unfocused on the people they are building their products for. I found that profoundly inspiring.
This is all to say that focusing on the end user is extremely important. Many people tend to say that IT is in the business of delivering great software products, which, put simply, is blasphemy! IT is in the business of providing value to its business. Otherwise, there is just no reason for IT’s existence.
A very effective way to keep your team end-user-obsessed is to shoot them with a Point of View Gun! However, if you don’t have one close by, please make sure that at all moments during product development (when designing, writing, refining, developing, testing, and ultimately demoing) you and your whole team systematically express themselves through the end user’s point of view—as if you were them!
That’s the reason why good user stories are written first hand, from the end-users perspective while unfolding their experience with the product. Using this technique, you are guaranteed to:
- Keep business value centered.
- Maintain common ground for understanding the behaviors and expected outcomes of a user story for all roles on the team (regardless of their technical background), as it is written in natural language.
- Detect hidden scope early, which leads to more reassuring estimates.
Step 6: Independent, Yet Connected
I’m sure that by now you already know what INVEST and SMART are all about, but, in case you don't, stop everything and follow this link. The point here is that although you can fill up a sprint with user stories that are INVEST and SMART bulletproof, they may not make any sense as a whole.
Have you ever sat through a demo where the product owner was plainly showing a series of unrelated, ad-hoc features? Was this a good experience? I’m pretty sure it wasn’t.
Storytelling is one of the oldest and most effective ways of passing down information, so in a sprint demo, you need to make sure that you tell a story from beginning to end in a fluid way. A good way to approach this is by presenting a real-life scenario, again, voiced from the end user’s point of view. This is the only way to make sure you keep your audience engaged throughout your demo and collect that much-needed feedback!
Your sprints must always result in yet another meaningful and valuable iteration. In fact, you have to plan for a series of in-sprint meaningful subsets of user stories so that you can share with your end users throughout the sprint mini deliveries to enable early feedback loops!
So on top of the mentioned principles for user story writing, you need to add one more, which is keeping in mind your overall sprint story and how each user story contributes to the whole.
Step 7: Less Is More
Say you’re creating a detailed, thorough backlog. While your intentions may be pure, falling back on more traditional requirements or specification formats isn’t the best way forward. What is supposed to be an easy-to-read user story becomes a full-blown, multi-page requirements specification document that’s made up of tangled intentions.
As a rule of thumb, a user story should never take more than 2 or 3 days to be developed. So whenever you feel that you may have written too much, you need to slice it up!
However, always remember to split your story horizontally by process steps and never vertically by your product’s technical layers. Splitting vertically often leads to reaching the end of a sprint with an incomplete feature—like Humma Kavula—delivering no real value that the end users can fully exercise.
Step 8: Manage Ongoing Discussions
At the end of our guide, it’s once again important to frame that you are doing agility at the enterprise scale. In this setup, it is normal for your team to be geographically widespread and have members from different nationalities and cultures, backgrounds, and age ranges.
Your development team (of which the product owner and scrum master are a part of) is a piece of a broader group composed by subject matter experts, business process analysts, architects, independent testers, and... I could go on.
You need to see the product backlog as the fuel of this big spaceship. If you feed it poorly, it will cause a lot of mechanical issues, and you don’t really want that, because otherwise you better be prepared for a surge of misunderstandings, meetings, problems, failed sprint goals, a lack of feedback, and low to no user adoption in the end.
As such, even if you are starting a sprint with the best backlog humans ever made, you better keep it fresh if assumptions change. You need to make sure that the broader team has the user story to go back to as a single source of truth. Because otherwise you will feel tortured every single day, going through all those nasty alignment sessions with all your stakeholders, no matter how much cakes there is at the meetings.
Pick Up Your Towel and Don’t Panic
When working at the enterprise scale, an agile team’s product backlog requires doubled quality standards. If done poorly, it will inevitably crash your spaceship. To avoid a crash you need to keep in mind:
- Smaller user stories are a lot easier to get across to everyone; write as little as possible to meet your intent, and then share it with your team so that you may build on top together.
- Be totally empathetic when writing, refining, developing, testing, and demoing a user story. Keep in mind at all times that your end user’s experience while using your product is the only way to stay true to the value you are aiming to deliver.
- Plan sprints that make sense as a whole so that the demo becomes a highly engaging experience for the audience. You need this to make sure people stay with you until the end and provide much-needed feedback.
- Be careful not to go overboard with your user stories. A healthy rule of thumb is 2–3 days of development for each user story. If you have outdone this, slice your user story in smaller, more meaningful pieces.
- Never underestimate the communication challenges of an enterprise-grade agile endeavor. Be sure to keep a single source of truth for everyone involved to support themselves with; it’s the only way to avoid chaos.
- Don’t panic!
Oh, and as usual, always bring a towel. A towel is about the most massively useful thing a hitchhiker can have. Happy adventures!