Common Challenges and Their Remedies Faced by Teams New to Scrum and Related FAQs

Net Objectives has been doing Scrum for almost 20 years. We have found patterns to challenges of teams just starting with Scrum and common solutions to them. Many of these solutions are integrated into our Lean-based Team Agility and our Scrum/ATDD.  We have found that many of these challenges can be avoided or at least mitigated by following the Learning Philosophy of Team Agility and Scrum/ATDD when a team first learns Scrum.

If you are already doing Scrum, you can also look at Introduction to Team Agility and Scrum as Example.  The first provides alternatives to Scrum’s immutable parts that achieve their intentions. The second views Scrum as an example of how to start and also provides alternatives and how to move forward.

Note: Those without links will be answered soon. If you want to dialog with Net Objectives’ consultants to get answers to your questions, please join our premium content which includes a discussion group just for that purpose.

Challenges

Common Challenges: There are seven challenges that most every team new to Scrum face. These are marked as “common” in the challenge. Our belief is that these challenges should be anticipated and included in initial training.

When you ask a Scrum Master what are the challenges facing her/his team, you often hear things such as, “We don’t do daily Scrums well,” or “I can’t get people to the retrospectives,” or “Product Owners don’t want to spend time with the team.” Notice that these are mostly challenges due to lack of motivation and understanding and is often the result of thinking of Scrum as a forcing framework instead of a supporting framework.

Challenges with quality of sprints

Challenges for Coaches

Events

Agile Product Management and Writing Stories

Organization of people and teams working together

Thought process

Want to be able to ask your own questions and get answers from experts? Check out the Net Objectives Community Bundle.

Addressing the challenges

Usually having several incomplete stories at the end of a sprint (common)

Going to 4 weeks is almost certainly a bad idea. In fact, I’d suggest if you did weekly sprints you’d like do better as that would really create more focus. This question is a good example of why thinking of Scrum as an operating model instead of a framework (as we do in Scrum/ATDD) is more effective. You would be following Scrum whether you did 2 or 4 week sprints. So little guidance is being provided. But consider this, “why are you spilling over tasks/stories?” There are any number of reasons we’ve encountered:

  • Stories are too big and hence have too many tasks (which are also likely too big).
  • Too many stories are being opened
  • Too many stories are committed to for the sprint which adds pressure to get them started
  • You have too many interruptions
  • There’s unplanned work because of poor quality

Shorter sprints will help you do the right thing, but it’s also useful to know what’s driving this behavior. Scrum. Lean-thinking would tell us to do the following:

  • Have small batch sizes (e.g., stories)
  • Manage your Work-in-Process (see the part ‘have a focus on finishing’)
  • Make all of your work visible in order to create opportunities to collaborate and get things finished sooner
  • Switching to a Kanban style daily Scrum will improve collaboration as well
  • If you are having many interruptions, track them with a special class of story. Include the side effect cost of the interruption and let management know how much of your velocity went towards them. This will educate them on why interrupting the team is a bad thing.

So bottom line advice is:

  • don’t have stories that take more than 3 days to do (estimate in story points though)
  • don’t open too many stories
  • make all of your work visible
  • use a kanban style daily standup

Using Test-First Methods can also help this problem as it makes for smaller, well-defined stories.

Note that having stories on the backlog that you haven’t started at the end of a sprint is a different issue.

If you have stories left in your sprint backlog that you haven’t started your only real challenge is over forecasting in planning. This error does not really cause any waste unless there are dependencies involved. Some teams are sometimes tempted to have longer sprints when this happens but that is typically a poor idea. Better to get your progress known more quickly with shorter sprints.

Too many stories get started early. (common)

When too many stories get opened the amount of Work-in-Process goes up and the level of collaboration across the team goes down. These are both bad things. This typically results from a tendency to prefer to start instead of a focus on finishing. The solution is to create agreements among team members to first look to help people out before looking to start something new. See Manage Work-in-Process for more.

Testing is not complete at the end of a sprint

Having testing lagging behind coding is an indication of one or more of several problems:

  • Different people are doing coding and testing. In Scrum these should not be separate roles. But if you do have people doing coding and testing it is critical that they do this working together or at least with high collaboration.
  • The sprints are done as mini-waterfall cycles. This delays feedback. At a minimum have those writing the code help those testing the code finish before starting new work when testers get behind.
  • Testing takes too long because of a lack of automated tests. Automate the tests.

These can usually be solved by using Behavior-Driven Development. BDD does not have to be a dramatic adoption, but can be started in phase. See How to start with BDD.

Running sprints as mini-waterfalls

Agile is not about running shorter waterfall cycles. It’s intended to build small pieces of value quickly. This both cuts out the delays during development as well as enabling quick feedback. To do this at the team level requires that features be decomposed into small, well-defined stories. The best way to do this is with a combination of Acceptance Test-Driven Development. You don’t need to even write the tests, but if you write specifications in a Given-When-Then format, they enable you to write small, clear stories. All teams need this ability from your first sprint on. It is therefore suggested if you are looking for initial training make sure your Scrum training includes writing your own stories.

Does frequent spill-over mean we should extend our sprint to four weeks from two weeks?

Going to longer sprints is typically not a good idea. If your motivation is you have incomplete stories at the end of your sprints, read Usually having incomplete stories at the end of a spring. If you are completing stories that have been started but have several left on the backlog  it may be you are just over-committing the number of stories. Another reason often given is that the testing cycle at the end of the sprint takes too long. If that is the case, read Testing is not complete at the end of a sprint.

Usually having several incomplete stories at the end of a sprint

Some teams complete there 1 or 2 week sprints but fear the overhead of the sprint is too high.  But the sprint planning and review should take about half the time for a 2 week sprint as for a 4 week sprint. The faster feedback should also save some time.

Getting people started with test-first methods

Many people think that you should start “test-first” with test-driven development. But TDD is often difficult to do with legacy code. The best way to start is with creating acceptance tests with Behavior-Driven Development (BDD) or Acceptance Test-Driven Development (ATDD).

See How to start with BDD/ATDD for more.  Also, see The benefits of BDD/ATDD.

If you are looking for Scrum training that has integrated test-first methods, see the courses in Lean-Agile at the team level.

Some Scrum Teams working on a different sprint length than others

A common situation in companies is having many teams do Scrum but having some using a different sprint length than the others. For example, most might be using 2 week sprints while a couple are doing 3 week sprints.  Most of the time this slows down the other teams since they have difficulty coordinating with those using longer sprints. I have learned a very useful question to ask those not doing 2 week sprints. I merely ask them “why” and listen, not so much to the reason, but as to who the reason benefits.

For example, let’s say the respond with either of these “we can’t get our stories small enough to fit into a 2-week sprint” or “the overhead of 2 week sprints is too high for us.” Notice how the benefits are to the team. They are focusing on doing Scrum at the team, for their team. Scrum is actually a team development framework so we should not be surprised when people use it to optimize their team.

But this should not be what Scrum is used for. It should be about how the team plays its part in the quick realization of business agility, predictably, sustainably and with high quality. The teams focus should be on how they contribute to this.

So, while it may not be in their team’s local interest to go to 2 week sprints, it may help them and the other teams they are working with go in two week sprints. When there is only one team local optimization is global optimization. When there are multiple teams teams need to consider this larger context they are in when they decide what to do.

Not being able to write small stories (common)

While the story format of “As a < type of user >, I want < some goal > so that < some reason >” is not a bad place to start, it is not always possible to use it to create small stories. Note that this discusses what the user wants. But goals and reasons don’t necessarily describe behavior. A much better format is “Given I am in <this situation>, when this <event> occurs, then I want this <behavior> to occur.” The “as a” method is nice in that it gives us goals. But it is not easy to get to small stories with it.  To do that, a lightweight use of Acceptance Test-Driven Development and Behavior Driven Development should be used.

Acceptance criteria is not well known for many stories

One of the biggest challenges in organizations is understanding what is really needed. The question “how will I know I’ve done that?” is not often asked. Rather teams act as if they understand what is needed. Or they go the other way and ask for detailed requirements that will ensure an understanding. Unfortunately, it is virtually impossible to get that much detail into a written document without also making the document unusable – “this report by its very length, defends itself from the risk of being read” – Winston Churchill. 

Stories need to have a well-defined acceptance criteria.

We have difficulty getting Cross-Functional Teams (Scrum/ATDD)

Cross-functional teams are great and you should try to achieve them. Before veering from cross-functional teams, consider how to improve a practice. When multiple teams are present, it gets harder and harder to actually manifest them. While it is good to attempt to get this immutable rule in Scrum, we’ve found it’s not always possible or viable. Subject Matter Experts are often in short supply. However, the intention of cross-functionality can often be achieved.  See Achieving Cross-Functional Teams to the Greatest Extent Possible

How does Lean-Thinking help people doing Scrum?

See How Lean Thinking Helps Scrum.