Bad Behavior on a Scrum Team

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

Cynthia Kahn  503.799.5500

Contact Us read more

Transition Your Team from Waterfall to Agile Scrum

My First Agile Scrum Project

The first question traditional waterfall development managers ask when they are looking to transition to agile scrum is, “How do I make this happen?” I’m going to share my first transition from waterfall to agile scrum five years ago and, hopefully, this will help you with yours.


I was a traditional waterfall project manager at a Fortune 500 international company. My team consisted of 2 developers, 2 quality engineers and 1 tech lead. The overall scope of the project was to procure and build the infrastructure from the ground up then to develop the following functionality: Email, Push, In-App and SMS.

Waterfall is OK for Architecture Buildout

We managed the procurement and buildout of the supporting architecture using the traditional waterfall approach, because there were simply too many dependencies on technologies and non-dedicated team members needing to do work outside of what would be an agile scrum team. We referred to this buildout period as Sprint Zero.

Begin the Transition from Waterfall to Agile

Sprint Zero

I obtained my Certified Scrum Master (CSM) certification and our team engaged an onsite scrum coach (similar to the services we offer at GSD) to train our entire team. Everyone on the team attended the training, including our new Product Owner.

Topics we learned included:

  • Defining Epics
  • Defining Sprint cycle
  • Story Writing
  • Backlog grooming
  • Estimating and assigning story points
  • Sprint Planning     
  • Daily Standups
  • Product Demos
  • Retrospectives
  • Reporting sprint velocity
  • Setting up and configuring tracking tool (JIRA)

Training sessions were spread over a few weeks to minimize disruption to the team and to allow them to complete their infrastructure buildout tasks. As a new scrum master, I worked closely with the team to ensure we were all aligned on how to implement agile scrum and how to be successful.  

Sprints 1 to 3

We decided to start with 2 week sprints as our coach advised this is optimum for most development teams. We have found 2 weeks to be the magic number with all our agile scrum teams. We also found this was a good amount  to analyze, develop, test, and document potentially deployable packages of code.

To ease the transition, our scrum coach attended all of our Story Writing, Backlog Grooming, Sprint Planning, Product Demo and Retrospective sessions during our first 3 sprints. Our scrum coach would be a silent observer in these sessions, but would interject if the team went off track or had questions about scrum.

This support gave our team, including our new Product Owner, confidence that we could fully function and deliver as a new agile scrum team. We wanted to demonstrate that we could quickly develop deployable code and show tangible work progress in a short amount of time. This was great because the team realized quick wins by demonstrating functional pieces of code. The Product Owner and stakeholders were getting continual feedback on the team’s progress. It was a win for everyone!

Operating Agile

I found the experience so amazing I knew I wanted to be an Agile coach. If we didn’t have ours, I don’t think we could have done it alone. The coach was crucial not only to training, but providing support to ensure we were embracing our new agile mindset and not falling back into waterfall processes. It also gave our stakeholders confidence we were working with an expert who could guide our team to success.

Let me know if you have any questions or need help with your transition to agile scrum.

DSC_4880 (500x483)

April Shepherd

April Shepherd  503.307.9072

Contact Us read more

April and Cynthia are GSD Gold

Applying Agile Scrum in the Real World

When I say the word agile and then add the words project management, depending on who you are, your response may range anywhere from “Heck yeah, this is the best thing ever to hit project management!”  to “Agile sucks, it does not work!” How can three little words evoke such a vast array of emotional responses? Because most project managers, developers, analysts, architects and development managers do not really understand agile and they do not correctly apply agile methods.

This is a blog about properly applying agile scrum to get stuff done in the most efficient way possible. Does the world need another blog about agile project management? Apparently, yes it does or else everyone in the world would no longer be using waterfall. Agile, particularly our method of scrum, helps everyone on any project successfully get stuff done, which is a very good thing.

What can you expect to learn from reading our blog posts and participating on our website?

  • How to organize an effective agile team
  • How to rethink your approach to project planning
  • How to setup sprints and monitor sprint progress
  • How to apply concepts of continuous improvement
  • How and when to release

Even more important than learning how to easily apply agile scrum techniques, we will help you shift your current project management paradigm to the agile mindset. Because without changing the way you think about and approach projects, you cannot become agile.

Why listen to us? Yeah and yeah, we both have our PMI PMPs and Scrum Alliance CSMs. We play the game. We both recently attended the PMI ACP 3-day training course, and we wanted to jump out a window within the first two hours. We needed the 21 PDUs, so we stayed the course. By the third day, we looked at each other and said, “Eff this, we can do better!” GSD was born.

That was 3 weeks ago. Now, we have a domain, a website and an outline. We’re agile. We’ll figure the rest out later.

Read our blog so you too can become more agile. We are 100% agile converts. We have taken the leap and left our old waterfall ways behind. We have successfully applied agile scrum to many development projects at multiple companies, big and small. Our agile teams outperform teams of our peers, even teams that also say they are agile too.

We are fun babes to hang out with. Hopefully, you will get as excited about agile scrum as we are. We want to save you from PDU suicide watch and make project management fun!Let’s start hanging out and working together to learn from each other and get more stuff done!

April and Cynthia

April Shepherd and Cynthia Kahn

April Shepherd and Cynthia Kahn

Contact Us


read more