Approaches that Improved My Scrum Team Performance

Many scrum masters ask us to recommend courses of action to resolve problems they encounter on their scrum teams.  There are common patterns of behavior that inhibit the effectiveness of agile scrum.

I’ve found the top 3 bad patterns of behavior are:

1. Product Owner does not participate on regular basis
2. Developers do not complete their stories until end of sprint
3. The Development Team does not time box the sprint

Pattern 1: Lack of Product Owner Commitment

We all know that the role of Product Owner is critical to the success of the scrum team. The Product Owner represents the customer, writes the stories, sets priority and answers questions the team has about story requirements. The time commitment is much more than that of Project Sponsor on traditional waterfall projects. New Product Owners can easily become overwhelmed.

So, what is a scrum master to do when the Product Owner starts missing standup and does not have stories ready for Story Grooming? As soon as you notice this behavior, schedule a 1-on-1 with the Product Owner.

Unlike most of the Development Team, the Product Owner may still retain responsibility for ongoing business functions. Or maybe the Product Owner is not getting the support needed from the rest of the customer base to adequately perform the job. Because the Product Owner holds such critical function, you need to find the root cause and address the issue.

If the Product Owner is spread too thin, ask if she is willing to share the role and assign someone from the business team to stand-in for them at meetings, so the role is always represented. Another option would be to share the role with the Business Analyst. Both suggestions can only work if the Product Owner delegates the decision-making process too. Whoever is assigned as a stand-in must also have the authority to reset priority, answer questions and resolve business issues.

The real issue may be the need for coaching. The Product Owner may need training writing stories or determining what work to prioritize first. If you have the bandwidth, coach the Product Owner with story writing. Another option is to pair the Product Owner with the Business Analyst, because Business Analysts have more experience writing requirements. If uncertainty around priority is the issue, pair the Product Owner with the Technical Lead or Architect, who may have better insight about what parts of the application should be developed first.

If the Product Owner rejects help, escalate the issue to your manager as a roadblock to team performance.

Pattern 2: Developers Do Not Complete Their Stories

We’ve all worked on scrum teams where most stories remain open until the end of the sprint, and then they magically close. Because agile stories cannot close until they pass Quality Assurance (QA), this symptom usually is accompanied by a mad rush to test over half the stories in the last day or two of the sprint. So, QA has nothing to do for the first week of the sprint and then has not enough resources to test the stories at the end of the sprint.

This mysterious phenomenon can have multiple root causes:

• The stories are too large
• The team does not practice pair programming
• The QA team does not create test plans early enough
• The Developer does not have the skill set to complete the story

You can tell the stories are too large if the largest story allowed to be brought into the sprint is sized an 8 and most of the stories in the sprint are sized a 5. If your sprint has no stories sized 1 or 2 or 3, then your stories may not be broken down into small enough components.

Remember that a story represents a slice of functionality that has value to the customer. Every story has to move your team closer to delivering the Minimum Viable Product (MVP) or Minimum Marketable Feature (MMF) set or completed Epic. It does not have to fully represent the final product. At the next Story Grooming session, see if the team can divide every 5 point story into a 3 point and a 2 point story.

If Developers are not pairing up to complete larger stories that cannot be divided into smaller stories, then suggest this at standup. Divide and conquer is a great team building and knowledge sharing strategy.

If stories are properly groomed with well-written acceptance criteria, then QA can begin writing test plans at the same time the Developer picks up the story. QA can also work with the Product Owner and Business Analyst to review requirements to determine what to test.

Plus, agile is all about self-managing teams. If most of the stories go into QA at the end of the sprint, it is perfectly reasonable to ask the Developers to help with testing. This is another excellent reason to write test cases early.

Sometimes Developers do not have the skill set to complete the story and they do not want to ask for help. If a story is languishing for any reason, always ask the Developer if he is blocked or would like to pair with another Developer. If the work does not progress, invite the Engineering Manager to standup. Let the Developer’s manager see first-hand what is happening and let him take next steps after the meeting. This subtle escalation approach often resolves the issue.

Pattern 3: The Sprint is not Time Boxed

Committing to scrum requires commitment by all team members to limit new development to only stories brought in at Sprint Planning. If the team breaks this commitment often enough, the team is no longer practicing scrum, but rather practicing scrummerfall, which is measuring random work completed in 2-3 week sprint increments. Scrummerfall is worse than waterfall, because the team is not working to any plan or schedule at all.

Symptoms that often lead to breaking the time box commitment include:

• Not bringing in the right stories
• Rewriting stories
• Emergencies occur

If the team is not bringing in the right stories, review the upcoming Epic milestones with the Product Owner to ensure the Backlog has the right stories and the right priority. Missing stories are a symptom that Epics are not broken down into all their components. Suggest the Product Owner review the Backlog with the Business Analyst and Technical Lead or Architect before the next Story Grooming session to verify nothing is missing and stories are brought into the sprint in the right order.  

If the team is constantly rewriting stories, then analyze the quality of the stories. Stories are business and process requirements, not mini specifications. Even technical stories should be written as functional requirements. That way, if the Tech Lead decides to change the way the story should be architected, the story itself remains valid as written.

As much as we want to time box and place boundaries around the work we commit to in the sprint, stuff happens. If the Development Team is responsible for a production application, production problems may occur that take resources away from sprint commitments. If production problems plague your team, first determine if your team has issues with quality new development. If the production problems are from an old application that the current project is replacing, then accept that production support issues will happen and plan for them.

If the team has production support responsibility, figure out how much of the sprint on average is spent resolving issues and buffer the sprint commitment. For example, if the team has a velocity of 40 story points and it spends 25% of its time on production support, then only take in 30 points next sprint. Add a zero-point production support story to the sprint each time a support ticket takes away from the team’s velocity. These production support stories do not add value to the project; that is why they get zero points. Keep track of these zero-point stories and escalate if the team’s lower velocity affects the ability to meet Epic milestones.

There are lots of reasons for team’s not being as agile as they could be. Hopefully, these suggestions get your creative juices flowing and enable your team to improve its agility.

I’d love to hear about how you’ve resolved these common patterns.
Please share your experiences in the Comments below,

Cynthia Kahn

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500