As a Product Owner, I have responsibility for the care and maintenance of the Product Backlog. The Sprint Backlog is owned by the whole Scrum Team. That said, I’m finding that Sprint Backlogs often get out of control. Here are the problems I have experienced:
Mysterious Stories Appear Out of Nowhere
What the heck? Where did that User Story come from? I have no idea where the story originated, or how it got slotted into the current Sprint. Do you have the same problem, where anyone on the teams feels free to add random items (that weren’t even in the Product Backlog) to the current Sprint? It drives me a little (LOT) crazy!
Technical Tasks Masquerading as Stories
Another problem I have seen crop up in Sprint Backlogs is technical tasks that are not stories at all – they’re just technical work. Anyone who knows me also knows that I am a huge opponent when it comes to “technical stories.” I don’t think they provide any direct, discernible value to the business, and I would not prioritize a technical story unless there was no other option. I always try to find a way to couple technical tasks with User Stories that do deliver something tangible that the business can see.
Priority and Ordering Keeps Shifting
One day, my Sprint Backlog is stack-ranked in priority order, based on my decisions as the Product Owner. But the next day, I notice that the order has changed. Things that were grouped are now split apart and what’s at the top of the Sprint Board is not the highest-priority item anymore. When anyone can move things around, the focus is lost, and it feels like a moving target (because it is).
No Story Naming Conventions
If your team is working on multiple requests from different business units or projects, it’s a good practice to have a naming convention for User Stories – otherwise, it can get confusing, and fast. I always try to keep things organized and follow a consistent pattern when naming my stories, but not everyone on the team does the same thing. The title may or may not provide me with the context I need to understand what the story relates to, but I’m still confused when I see one-off stories that don’t follow the naming conventions.
Empty Story Cards
Oh, yeah. This is one of my biggest pet peeves. Stories that are not properly written, with all the necessary information to execute should never make it into the Sprint Backlog. If the team hasn’t defined a “Definition of Ready,” this could help alleviate some of this, but it probably won’t stop it from happening entirely. If there are no details, someone on the team should call it out, and then work together to populate the story with the information needed. If not, kicked it back into the Product Backlog.
No Story Points
When a Story in a Sprint Backlog has no Story Points assigned, it’s a “clue” that the story wasn’t properly evaluated by the team or refined. Story sizing should be done by the developers (ideally ahead of Sprint Planning during Backlog Refinement). Stories without points are useless, and without points, it throws the whole system out of whack and messes up the metrics such as average velocity. Like missing details, someone on the team should notice that there are no points, and the story should be sized immediately (or go back into the Product Backlog).
Orphans (Unparented Stories)
Stories that are not parented to a feature or epic are orphan stories. How do I know what they’re about and where they fit in the grand scheme of things? I don’t! Every story in the Sprint Backlog should have a traceable lineage. And ultimately, all items should be tied to some kind of strategic goal, or why are we wasting our time doing it? I also keep a “Miscellaneous” bucket, because sometimes (rarely) there are legitimate reasons why a story doesn’t have an obvious parent. Every story should have a parent.
Ad Hoc Requests
Stuff just comes up ad hoc, and instead of bringing the story to me (as the Product Owner), team members just add new items that crop up willy nilly. Items that have been pulled into the Sprint Backlog need to be negotiated with the Product Owner, not just get added like adding fries to a burger order. Usually, if something new is added, something else needs to be removed – every new item requires a tradeoff (you must give something up to get something else).
Burndown is Going Up, Not Down!
That burndown chart that is supposed to steadily burn down throughout the Sprint is going in the wrong direction! When I see a spike up and to the right, it tells me that more work got added to the Sprint Backlog, or that some tasks are taking more time than originally estimated. It may also be an indicator that the team members aren’t updating their “time remaining” on active tasks at the end of each day. The Scrum Master should be paying attention to this and challenge the team about what is going on.
No Attention is Paid to the Average Velocity
The average velocity metric is meant to help guide the team in choosing a reasonable amount of work that they should realistically be able to accomplish within a Sprint. However, teams routinely ignore this information. Instead of taking this number as a serious tool, they try to do way more than the team could ever achieve. This leads to stories being carried from Sprint to Sprint, which is demoralizing to the team and disappointing to stakeholders. Velocity should be used to limit the amount of work planned for a Sprint.
Making Updates to the Sprint Backlog During Scrum
Another of my pet peeves happens when updates are made to the Sprint Board during the Daily Scrum. Again, this is caused by team members not updating their tasks. It’s a waste of everyone’s time to make updates on that call – it’s meant to be the developers’ time for planning what they will accomplish that day, not maintaining the board. This work should happen before Scrum every day – not during it.
Cherry Picking Stories
Another issue I commonly see is developers cherry-picking stories rather than going in the priority order from top to bottom. They often do this because some stories are easier or more desirable than the most important ones. What does this result in? Delivering the wrong things in the wrong order. Ideally, the Sprint Backlog is stack-ranked, and the team takes that order seriously. Just like the Product Backlog, items lower on the Sprint Backlog should not be looked at before things at the top.
Conclusion
If your Sprint Backlog is out of control, it might be a good opportunity to explore with the team in a Sprint Retrospective. We could do a grading exercise of the last Sprint Backlog and identify issues (like the ones listed in this blog). From that, we would choose the most impactful mistakes and target fixing those in the next Sprint.
How about you? Has your Scrum Team experienced any of these issues? Are there any other problems you face with managing your Sprint Backlog? If so, I’d love to hear about it, so please share it in the comments below!