Webinar Recap: The Evolution of a User Story
User stories are a staple in Agile but it can still be a tough practice to master, particularly for newer teams. A user story is defined as a short description of a feature or product told from the perspective of the end user or customer. They typically follow the same simple format:
As a < WHO >, I want < WHAT > so that < WHY >.
Many Product Owners we work with find themselves struggling with when and how to break their epics down into actionable user stories. Another challenge? Team members get frustrated because the user story doesn’t capture all of the details needed to begin work and complete it successfully.
How do we fix this?
Our Agile Coaches, David Hawks and Braz Brandt discuss the “when” portion of breaking down epics into user stories and how you can get into a regular cadence of evolving your backlog through collaboration between Product Owners and the Dev Team in this recording of our December webinar, The Evolution of a User Story.
Q&A Transcription
1. Looking at the lifecycle of a User Story, as a Product Owner, how do I how do I balance PO responsibilities (stakeholder management, decomposing epics, etc.) with being available to the team so that they can continue to be a high performing team?
David: There’s actually some language that’s been lightening up in the Scrum Guide around who actually does all the work. Traditionally, it’s been the PO who does all the data entry and whatnot after Backlog Refinement. Now, it’s something that the entire team might help finish. When the PO is overloaded, the team needs to recognize that and find ways to relieve that pressure.
2. Where do things like Behavioral Driven Development (BDD) or writing in a Gurken format (given…when…then…) tie into the traditional User Story format?
David: So some people use these formats for writing acceptance criteria, and that can be helpful. For me, that can sometimes be extra overhead. I think teams might take things too far at times.
If you’re writing acceptance criteria in more readable language, and then those acceptance criteria then become automated tests, that can be pretty valuable because we’re not having an extra translation step. However, if you’re not doing BDD, and not actually automating those tests, then it might be too much extra ceremony or overhead for the team.
My advice is to make sure that you’re keeping a balance when trying either of these methods.
3. I find it near impossible to write plumbing type stories from the user’s perspective. I run a small team, so our velocity doesn’t always allow for user value in a single sprint when plumbing or re-plumbing is required. What is your advice? [Plumbing meaning the database code, the API layer, service, microservice, etc. The stuff underneath the product.]
David: Let’s take a look at this diagram:
What we see a lot of times is that teams are structured in terms of database, middle tier, or UI, etc. What we don’t want is to write a story from a component or architectural dimension. That’s not actually a valid story. So that’s probably the challenge that you’re running into: You’re trying to write a story for something that is actually a task. We need to think about writing the story from the user’s perspective. This could be a challenge for your team for multiple reasons:
- Your team is made up of just people from that plumbing level (like one of the black ovals in the diagram). This could be problematic because then you have a component team. These teams are challenging because they don’t have all the capabilities to deliver a user story. So in Agile, when we talk about creating cross-functional teams, we mean a people from different levels creating a feature team, so that we get multiple capabilities and perspectives to form a functional user story.
- You don’t need a user story for the issue! The re-plumbing question is a good example of this. This issue likely comes from a case of already having the functionality, but now there’s technical debt problems or refactoring that needs to be done. In that case, a user story might not be necessary. Remember, we don’t have to force everything into this user story format.
4. How do you handle stories that are highly technology driven? For example, an internal department delivering to a larger organization’s IT developers?
David: The first test I’m always going to apply is “Can we build a cross-functional team to simplify dependencies?” The Agile answer is to put as many of the dependencies on the same team as we can so that they are all working together. Conway’s Law tells us that we have a tendency for any structure built within an organization to mimic the organization’s structure. That creates issues in technical structures because it causes us to overcomplicate our technical architecture which can make it difficult to put all of those skills onto one team. Sometimes, it’s more than just putting people together and more about taking a look at that technical architecture and perhaps refactoring.
Now let’s say we have done all of that. At the other end of the spectrum, there’s a scenario where you need a system persona. Say the “customer” that you’re writing code for is a pharmacy system. In that case, it’s okay to write a user story from the perspective of that system persona. The team that writes that user story might not have a UI because they only deliver to that pharmacy system, and that’s just fine!
What we don’t want to do it abuse that technique.
Braz: Yeah, I’ve used that method quite a bit. It’s important to be thorough when it comes to external vs internal users so that you don’t get mixed up. It’s all about understanding the user perspective.
5. Your example involved 16 weeks of backlog refinement before the first sprint starts for the new features, but I often have a hard time getting the backlog refined 4 weeks prior to the start of the sprint. What is your advice?
David: First, when I think about the backlog, I think about it like this:
There are things at the top, maybe some larger ones in the middle, and maybe even some extra large items at the bottom. Typically, we want this backlog to have at least 2-3 sprints worth of ready stories. Some teams even like to include a Definition of Ready (DOR). So by the time we get to Sprint Planning, we have the top 2-3 sprints worth of stories refined.
Also, we want everything that’s in our current plan or forecast is sized—they all have an estimate on it. We want all of these things sized so that if something new needs to get added to our backlog, we know what/how much needs to be taken away to still keep our forecast on track.
If the stakeholders or teams are slow to provide necessary feedback, maybe you just need to set some time on the calendar, get them all in a room for an hour or two, and get stuff done. Incorporating a consistent cadence of backlog refinement with the team into each sprint could help you stay on top of your backlog as well.
6. The previous question mentioned 16 weeks worth of work. How does that translate into actual time spent for the team? Also, what are your tips on accelerating conversations with the team when it comes to trying to get everyone into the room and providing feedback?
David: As far as tips go, I would start by breaking it down. Let’s first take a look at how much time is truly spent with the team over those 16 weeks. If we spend 5 minutes in our first meeting with the team where we do rough order magnitude, then maybe 15 minutes in a Backlog Refinement session, then another session where we spend 10 minutes breaking down some stories into tasks, then time totals to somewhere around 30-45 minutes total as a team actually working on backlog refinement.
Braz: If refining the backlog becomes a team effort in Backlog Refinement, then the work of inputting things into Jira or on a board becomes something anyone can do.
David: If it’s the highest priority, then the team should swarm to get it done.
7. UX activities – how do you recommend accounting for these in context of User Stories? Do you recommend creating User Stories for UX work or define these as self-standing tasks or subtasks, tasks, or simply as acceptance criteria for User Stories?
David: It sounds like the first question we should ask is if the UX person is working as a member of the team or outside of it. That’s going to dictate your solution. Having that UX person as a member of the team is obviously going to be more ideal.
If the UX person is a member of the team, then we want to make sure all of our work is visible. How do we do that within a tool, like Jira? It’s not always simple, and there’s not a perfect answer. I have seen teams create a Jira ticket—not really a user story—as something to create visibility. These tickets are simply there to show what the team is working on. It could be called something like “Prepare for Stories 1, 2, and 3”. Tasks associated with this could be things like meetings. While this isn’t necessarily work that takes place under a story, it is reflective of what the team is really working on.
So don’t get too hung up on making everything a user story. The focus here would be to make your work visible to the rest of the team.
8. Do you create separate “user stories” (or some other card type) for technical work that needs to be done to realize a User Story? Like “Create Database Scheme”, or “Do Development Work”, etc.? If so, what do you call these card types, and what content do you put in them?
David: From a Scrum definition, we would call those tasks. Jira would call those sub-tasks—not to be confused with Tasks, Jira’s straight-out-of-the-box version of a User Story. Most of the time, these sub-tasks underneath user stories don’t have much detail at all. The reason for this is that the whole team is present as they’re being created and we’re only creating these sub-tasks for the next two weeks. If we were creating them 6 months in advance, we’d probably need more detail to recall what the heck we were talking about. When we’re only planning for a two week sprint, they’re fresh in our collective mind and we don’t need all of that extra work to be done.
As far as documentation of design and other things, Jira isn’t the place for that. Instead, you can put that on your favorite Wiki software, like Confluence. Sub-tasks or tasks are very transient things—they should go away after two weeks. If you have a co-located team, we even recommend tasking on a physical board where tasks are sticky notes on a wall so that you can just toss out the sticky notes at the end of your two-week sprint. Your stories should, of course, be documented in Jira, but the tasks aren’t meant to be extensively documented. You just don’t need it.
Braz: This takes me back to User Stories 101—it’s the 3 C’s. We can have a ticket and the ticket can describe some user value, but the ephemeral conversations that we have on a day-to-day basis about how we’re going to turn those tickets into real-life user value. Also, how we’re going to capture the outputs of those conversations in things like delivered software, just-enough documentation, and long-term artifacts.
Looking for more information on user stories? Check out these articles:
4 Characteristics of a Personable and Useful Customer/User Persona
Leave a Reply