As an Agile coach, Scrum team members will sometimes say to me, "I don't have anything to do. I did everything I can think of to do in this sprint's backlog, and I don't have any impediments to raise. What should I do now?"
In traditional development, of course, you would go to your manager in this situation, and your manager would give you some more work to do. In Scrum, however, figuring out what to do next is your job, not your manager's. And that's good, because you and your fellow team members have a better sense of the moment-to-moment needs of the team than anyone else does.
Here's the four-item checklist I usually give to Scrum team members who are trying to figure out how they can best contribute to the team in these situations:
1. Swarm — First, try contributing to a sprint backlog item that's already being worked on by one of your colleagues. If your team is using pair programming, then this step is easy—pair up with one of your teammates and help them complete one of the items that they have in progress. If your team is not using pairing (you should try it! — let me know if you want training or coaching) then you will need to display some adaptability. Reviewing code, reviewing test cases, or executing manual testing are sometimes good choices for ways you can help with stories that are currently in play, but there's lots of creative ways you can work together as a team on stories. High-performing Agile teams work at a much higher level of collaboration than non-Agile teams do, but that collaboration doesn't just happen; you yourself must invent what effective collaboration looks like for your team. It takes work to figure it out. That work is your work.
2. Pull — If you can't figure out how to contribute to any of the team's backlog items that are already in progress, then it's time to consider whether your team can pull more work into this sprint. Remember: a Scrum team only starts work that it can complete during the current sprint, so you should only consider pulling in items from the Product Backlog that can be started and finished before the end of the sprint. If you find a good candidate for an item to pull in, then before pulling it in, confirm with the full Scrum Team (Product Owner, Scrum Master, and all Development Team members) that this item
If everyone agrees that all three of these criteria are met, then go for it. Remember that you by yourself can't make the decision to pull more work into a sprint. The decision to pull in more work affects the whole team, not just you, so you need the whole team to agree to it. Getting that agreement doesn't have to be a big deal: you can make your case for pulling in the new item by bringing up the topic after one of your daily standups. This discussion can be a lot easier if your Scrum Team has a functioning sprint burndown chart, so you can all see whether the team is ahead or behind on the current sprint's work. If the Product Owner, Scrum Master, and Development Team members are all cool with pulling in more work, then make it so. If they aren't, however, you will have to choose another option.
3. Team++ — Suppose you can't figure out how to swarm on the current work, and the team pulling more work into the current sprint isn't the right thing to do. What then? Another option is for you to work on something that will upgrade the team's capability to get useful, high-quality work done in future sprints. I'll bet your team has a huge amount of pending work that falls in this category, even if no one might have formally written this work down. Here's some types of "Team++" work that occur to me off the top of my head, to give you a sense of what I'm talking about:
Any team that is rapidly delivering working software will always have some of this unexciting-but-crucial cleanup work to do—it's part of the game. Scrum is designed to give you opportunities to clean up, clear the decks, and organize your team's environment in a way that will make the whole team maximally effective over the long term.
Please note that "Team++" is not an invitation to get a head start on items in the Product Backlog that haven't been pulled into the current sprint. There is no "head start" in Scrum. Scrum Teams only work on the items that they reasonably believe they can finish in this sprint. Everything else in the Product Backlog can wait—you'll get to it eventually, I promise.
4. You++ — Supposing none of the previous options seem like the right choice, what then? Perhaps that means this is the right time to upgrade your own skills. That could mean shadowing a fellow team member to learn from them or doing coding kata or completing online training or reading a technical book or something else entirely. You always need to be learning new skills or deepening your knowledge of existing skills. Don't let the pressure of sprint work deprive you of the time that you need to develop yourself. Learning is part of your job too—make time for it.