12 Tips for Product Owners who want better performance from their Scrum Teams
As Product Owner, I want better performance from my Scrum team.
Jeff Sutherland observed that teams in the 95th percentile were 10 times more productive than average teams (50th percentile). He created Scrum to enable all teams to recreate those conditions that enable top performance.
How do you really get better performance from your Scrum team? It’s not about cracking the whip. That is usually counterproductive. It’s about creating the right conditions. In my Product Owner course, we look at the many tools available to Product Owner to enable better and quicker results from the development teams. Here is a summary of what we covered this week/what you can do to get better results from your Scrum Development Team:
- Encourage Focus – the top priority story is must have, everything else nice to have until that story is done. Multitasking is evil! Make sure your team understands that in the sprint planning.
- Encourage Focus on getting things done! Unfinished work is evil! (Unstarted work is OK, though!!) If your team is leaving much unfinished work at the end of the sprint, ask them how they can leave less undone work at the end of the sprint. Insist on it, too!
- Accept stories one at a time during the sprint. If you wait until the end of the sprint to accept stories, this requires a huge effort from you on short notice to get things approved. Necessary changes and fixes are unlikely to be finished before the end of the sprint. Everyone’s life is easier if you can approve individual stories during the course of the sprint.
- Keep stories small and make sure they are ready. Small stories have simpler acceptance criteria and easier interfaces to other stories. A good minimum is 6 to 10 stories per sprint. That means that each story represents about 10 to 15% of the teams capacity. Even smaller stories are OK too.
- Eliminate undone work. Ask your team at the end of the sprint, “is this really done? Can we release this?” If this were an airplane, would you want to be onboard for its maiden flight? If the answer is no (or even, “yes, but…”), then you have undone work. This work needs to come on the backlog. And you need to ask your team to reflect on how to have less undone work after the next sprint. Insist on a good answer!
- Good engineering practices. Ensure your team can learn and use practices like: Pairing, Continuous Integration, Test First, Continuous Deployment, devops… You can’t tell your team to do these things, but you can ask questions like: How does stuff that was done last sprint stay done this sprint? All of the top performing teams use top engineering practices. (Did you know, Google executes 10’000 unit tests per employee, every day?! How many does your team do?)
- Throttling, or “Less is more”. You can’t give the team more work than feel they can complete, but you can give them less. If the team has a lot of unfinished work, reduce the work you give them in the next sprint. Limiting the number of stories to the Team size divided by 2 is a good place to start (assuming the stories are small as described previously). This does encourage them to pair and really solve problems as a team. Of course, if they run out of work, they can always ask you for more.
- Shorter sprints. If your team failed to deliver in two weeks, they usually ask for a longer sprint. But if they can’t properly gauge their abilities over two weeks, they won’t be able to do it over three weeks either. Go for a one-week sprint for a few weeks. A couple of 59 minute sprints can be a great learning exercise!
- Work closely with your team. Don’t make them wait for an appointment. Plan to be nearby, especially right after the Daily Scrums and second half of Sprint Planning.
- Do the true must-haves first! Start with the stuff your users will use every day. Get to a minimally usable state as quickly as possible. That minimally usable state is probably an order of magnitude smaller than you think it is. Focus on the essentials, and add luxury and flexibility later.
- Say no. Don’t develop features no one is going to use. According to studies, 45% of features developed for own use are never used at all. Another 19% are only used infrequently. Get rid of them, and you improve productivity by a factor of three!
- Give your team the help they ask for! Whether your Scrum team asks for people, skills, equipment, software, help implementing ideas from the retrospective, or even a party, if you can, make it happen! You might have a discussion about when, but not about whether. This is servant leadership!
Bonus tip (1): get the team right. The relationship between team performance, size, and composition is not obvious. Smaller teams can be dramatically faster than big teams. Even splitting a big team in two can be hugely beneficial for overall performance. And the guru that everyone depends on may in fact slow the team down.
Bonus tip (2): give the team the problem, not the solution. The team’s job is to solve problems and challenges posed by the Product Owner. If you are giving them solutions rather than problems, you are probably demotivating your team, possibly leading them down a suboptimal path, and surely replacing 7 brains (those of your team) with just one (yours). This is one of the key differences between a Product Owner and a business analyst. The business analyst gives the developers the solution, whereas the Product Owner gives them problem.
Finally: Give the team enough space to develop! You have your space, the Development Team has its space. The Scrum Framework is designed to give the Development Team enough space to develop its full potential. As you and your Dev-Team learn to work together effectively, you develop your own patterns that work especially for you! So start by respecting the team’s space, learn the dance of the Scrum Team, and watch the productivity soar!
Want to learn more and learn why? Come to my Scrum Product Owner course!
Performance Improving Strategies learned in my last CSPO course
