As a Business Analyst with extensive agile experience, I have seen teams at all levels struggle with how to manage work when they make the transition to agile. Teams that can address the following pain points early will see success early and often in their agile transformation journey. From starting without a backlog to having too much work in progress, getting in the right rhythm with your team can be the key to success.
1. Starting Without a Product Backlog
When you get started with an agile project, I encourage you to have at least something in the product backlog when you start sprinting.
It’s OK to start with nothing, but it’s not preferred. If possible, you want to have at least enough for the team to pull in one or two sprints worth of work. It doesn’t have to be complete or perfect, but it helps the team get off to a good start if they have solid product backlog items to pull into their sprint. As they start sprinting, the Product Owner and their support team can continue to build out and refine the backlog.
The key here is to not get too far ahead. Try to be no more than two or three sprints ahead. Your backlog might also depend on how long your sprint length is. If you get too far ahead, there’s a chance that the work you do will be irrelevant by the time it comes time to look at it, and you’ll have to do wasteful rework. You want to avoid that. The mantra is to get “just enough, just in time”.
Another key point that a lot of teams I’ve worked with have missed is that they need to have a definition of “ready”. When I’m coaching and forming new agile teams, part of the team launch is to create that definition of ready so that everyone understands what a ready story looks like. Typically, it means they’ve had the three Cs (Card, Conversation, Confirmation – credit to Ron Jeffries), there is documented acceptance criteria, the Product Owner has approved it, and the story has been sized appropriately. That is a simple definition of ready that I think most people could agree with, but each team should come up with their own definition of ready.
2. Decomposing Work into Bite-Size Chunks
Another pain point that teams run into is knowing when to break items into smaller pieces. The rule of thumb is, “Can it be done within a sprint”?
That is going to vary, depending on how long your sprints are. Each team might have a separate rule that helps them determine whether it’s too big. I’ve worked on teams where a story size of eight was the rule. If we had a story that size, it was a clue that it was too big, and we needed to break it into smaller pieces. For another team, it might be a 13, or it could be other rules like complexity. The key is to make sure you can complete the work within the sprint.
How Do You Break Down a Larger Story?
There are many ways to split those larger stories. I recommend splitting them vertically instead of by horizontal system layers. This way, you are going to make a thin slice through all the layers to get a small, discrete function completed. Some examples include:
- Workflow steps
- Input options
- Test cases
- Business rules
- Data types/parameters
- Acceptance criteria
- Happy/unhappy path
- Operations (Create, Read, Update, Delete)
- Roles
(Source: Christiaan Verwijs)
This is the just the tip of the iceberg, though. There are at least 25 techniques I know of that I will be blogging about soon, so be sure to check this blog for those coming up.
3. Managing the Flow of Work
I’ve also seen problems where there is way too much in the Product Backlog, and no one can figure out what to do – as well as the opposite problem where there is not enough to do, and it’s hard to keep the team fed with high-quality, ready work.
The key is to get just a few sprints ahead, make sure you have a definition of ready, and ensure there is enough work for the team. Again, don’t go too far ahead, or you’ll have waste and re-work. If you don’t have enough work to go around, many companies get concerned with team utilization because it’s the metric they care about the most. But in agile, you need to let go of that.
Here are a few things you can do if you have spare time in a sprint:
Adjust the Team
If spare time is a regular thing, you might need to consider adjusting the team size. If this is a consistent problem, and you never have enough work, maybe your team is too big. Maybe you need to make a few cuts to the team – that might be kind of hard, because it feels like throwing someone off the island. But you might have to do that sometimes.
Help Others
You should be helping someone else on the team if you run out of things to do. If you got everything you signed up for done, then go ask your team members if they need any help. Your goal there is to meet your sprint goal and get everything to done so you have that fully working increment.
Learn Something
Also, you might take that as an opportunity to learn something new. The more general knowledge the team members have, the more value they are going to deliver to the team. Take the opportunity to learn a new technology or skill. Likewise, you could do some market research and help the Product Owner do some benchmarking or competitive analysis. You want to understand those things, and you can help the Product Owner with that.
Clean Up Technical Debt
This is also a great opportunity to clean up technical debt. I don’t know of any company, ever, that didn’t have any technical debt. If you have technical debt, make it a “go-to” activity if you run out of things to do.
Pull Something
Last, but not least, if you are in the situation where everything has been completed, you can always pull something if it meets the definition of ready. But only pull it in if you think you can complete it within the current sprint. If you can’t get it done, I wouldn’t encourage pulling it and having it be not done. You could maybe get a head start or do some research, but don’t pull it ahead unless you feel like you can complete it. Or negotiate with your product owner on something lower on the product backlog that is of a size that could be completed.
4. Too Much Work in Progress (WIP)
Finally, having too much work in progress is a recurring problem I’ve seen on different teams where they have a lot of items that they pulled into their sprint backlog. (And it ties into the last pain point.) The developers on the team will pull an item, start working on it, maybe get stuck (but not raise an impediment) and then start working on another thing. And then another thing, and then another thing until they’ve got six or seven items currently in progress. That’s not the best way to operate when you’re in agile.
Focus on Priorities
The key is to focus on the one item at the top, the highest-value, highest-priority thing until it’s done. If you have something that’s in your way, raise the issue. Get the impediment removed so you can get to done.
Set WIP Limits
You should also consider setting a work in progress limit. This is more of a Kanban idea, but I think it works well in Scrum, too. Maybe have a rule for your team that they can only have two active work items in progress at a time – this might be manageable. We just want to limit it so your team is not multi-tasking – which we all know is not very effective. That way, they’ll be able to focus and get things to done.
If you continue to have the problem where there are too many things in progress, you’re basically going to go back to where you were before you started Scrum/Agile. It’s kind of a waterfall problem where you’re assigned to a dozen different projects, and you’re working on them a little bit at a time, and nothing is ever going to get done. Put that away and just focus on one or two things and get them completely done. There are no real productivity gains or efficiency benefits in multi-tasking.
Finding the right backlog and work balance in your agile team can be challenging, but teams that can manage workflow are on the path to agile success.
