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 approach to Scrum.  We have found that many of these challenges can be avoided or at least mitigated by following the Learning Philosophy of Scrum and Team Agility 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.

When looking to improve your practices, you can’t just drop one without considering its affects on the whole. There is a disciplined process that must be followed.  See how to improve a practice for making changes to help any of the following challenges.

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

• Challenge: Usually having several incomplete stories at the end of a sprint. (common)
• Challenge: Too many stories get started early. (common)
• Challenge: Testing is not complete by the end of the sprint.
• Challenge: Running sprints as mini-waterfalls (common)
• Related FAQ: Does frequent spillover mean we should extend our sprint to 4 weeks from 2 weeks?
• Related FAQ: How can I get people more interested in doing test-first methods?

Challenges for coaches

• Challenge: Some Scrum teams working on a different sprint length than others.

Events

• Challenge: Having ineffective daily Scrums.
• Challenge: Estimation with Planning Poker takes too long.

Agile Product Management and writing stories

• Challenge: Not being able to write small stories. (common)
• Challenge: Acceptance criteria is not well known for many stories. (common)
• Challenge: Product Owner Not Available (common) coming soon
• Challenge: No Definition of Ready or Definition of Done (common) coming soon

Organization of people and teams working together

• Challenge: Some people needed on a team in order to make it cross-functional are not available full time.
• Challenge: Teams that work together being on different sprint lengths

Thought process

• FAQ: How does Lean-Thinking help people doing Scrum?
• FAQ: How can we tell if a suggested improvement will actually help?

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)

Some people suggest going to longer sprints is the way to solve this. But that merely hides the problem. Going to four weeks is almost certainly a bad idea. In fact, if you did weekly sprints, you would find yourself doing better because it creates greater focus. This question is a good example of why thinking of Scrum as an operating model instead of a framework (as we do in the Net Objectives approach to Scrum) is more effective. You would be following Scrum whether you did two or four week sprints. So little guidance is being provided. But consider this, “why are you spilling over tasks/stories?” Here are reasons we have encountered.

• Stories are too big and hence have too many tasks (which are also likely too big).
• Too many stories are being opened
• The team is running mini-waterfalls in a sprint
• 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
• People writing code are not collaborating sufficiently with people testing the code
• Development teams are not collaborating sufficiently with shared services teams
• You haven’t written acceptance tests prior to starting code (they do not need to be automated)

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 (such as stories).
• Manage your Work-in-Process.
• Make all of your work visible in order to create opportunities to collaborate and get things finished sooner.
• Switching to a Kanban style Daily Standup 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.

Here is the bottom-line advice.

• 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

This article is on a separate page since it is referred to by several pages. See Tests are not complete at the end of the sprint.

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

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.