When a new Scrum Team first starts working together, they go through some common growing pains. Knowing what to expect for a new Scrum Team can help make things go a little smoother.
Below are some common growing pains for new Scrum Teams:
1) There isn’t enough work in the Product Backlog - This isn’t an indictment of the Product Owner. It’s not their fault—this is to be expected. When a Scrum team first forms, there may not be much in the Product Backlog, and that’s OK.
You might be tempted to run a “Sprint Zero,” where the Scrum Team spends time just building out the Product Backlog. I would advise against it. Not only is this not a concept in the Scrum framework, but you don’t need it. I actually tried it once. After two days, the team was bored and asked to start Sprinting.
What to do about it: You don’t need a fully fleshed-out Product Backlog to get started. Use the first Sprint Planning event to collaborate—Product Owner, Developers, and Scrum Master—on what would bring the most value in the first Sprint. Create a Sprint Goal and a plan to achieve it. Then get started. You’ll learn more doing that than you ever would with even six months of planning.
2) Incremental delivery is a struggle - New Scrum Teams often don’t finish all the work they planned by the end of the first Sprint. There could be several reasons: Product Backlog items may be too large, the team may not understand the tech, or they may have simply pulled too much work in. This is typical for new teams—they’re still learning how much work to plan for each Sprint.
What to do about it: Discuss it in the Sprint Retrospective. Ask the team why they think it’s happening. The root cause is often that items are too large, and the Scrum team may need to work with the Product Owner to size Product Backlog items so that each one can be completed within a single Sprint. Alternatively, the team may need to limit work in progress so that developers focus on one or two stories at a time, not five or more. Too much multitasking leads to context switching and unfinished work. Let the Scrum team discuss it in the Sprint Retrospective and come up with one or two improvements for the next Sprint. (Note that completing everything originally planned during the Sprint is not the goal, but having a lot of work that doesn't get to "Done" causes disruption - the Scrum team must find their own balance of how much work to plan.)
3) Role clarity is fuzzy - Early on, team members may not be too clear on boundaries. Should Developers be deciding what to work on? Should the Product Owner weigh in on how something is built?
What to do about it: The Scrum Master should actively coach the team. The Product Owner is accountable for what the team works on. Developers are accountable for how they deliver it.
I like the analogy of hiring a contractor to remodel your kitchen. As the customer, I decide what I want—maybe new countertops and tile—but I don’t tell the contractors how to do the work or how long it should take. That’s their expertise. Thinking of your team like that can help reinforce why it’s important for everyone to stay in their lane—it builds trust and helps the team work better together.
4) Event effectiveness is low at first - When a team first starts using Scrum, the events—Sprint Planning, Daily Scrum, Sprint Review, Retrospective—might feel awkward or clunky. That’s normal.
What to do about it: Don’t expect perfection right away. It’s OK if the events feel awkward. Just stick to the timeboxes from the Scrum Guide and give it time. The events will improve as the team learns how to apply Scrum in their context.
5) The artifacts feel like a moving target - In Scrum, the three artifacts are the Product Backlog, the Sprint Backlog, and the Increment. Early on, the team may frequently change how they structure the backlogs—and that’s totally fine.
What to do about it: Check in during the Sprint Retrospective to see if the team wants to adjust the format of their boards or documents. There’s no perfect way to visualize the Product Backlog or Sprint Backlog. Some teams use tasks, others move full Product Backlog items across the board. Some use different column setups. That’s all OK. What matters is finding what works for your team. (Want ideas? Join us at Scrum Day Madison to see how others improve their Scrum boards in Jira.)
Conclusion
Nothing is perfect on day one. But Scrum is based on Empiricism, which means we’re transparent about what’s working—and what’s not—so we can inspect and adapt. That goes for the product, the team’s process, and the tools we use.
Don’t expect perfection. Embrace continuous improvement.
***
Rebel Scrum is the host of the annual Scrum Day Madison conference.