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 / Agile Product Management (Scrum/APM).  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/APM 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.

Activities

Challenges with completing a sprint

• Challenge: Usually having several incomplete stories at the end of a  sprint.
• Challenge: Completing stories that were started but not completing all of the stories in the sprint backlog.
• Challenge: The time for testing take too long to complete in a sprint.
• Related FAQ: Does frequent spill-over 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?

Events

• Challenge: Having 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.

Organization of people

• Challenge: Some people needed on a team in order to make it cross-functional are not available full time.

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 our Community Bundle.

Usually having several incomplete stories at the end of a sprint

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/APM) 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.

Completing stories that were started but not completing all of the stories in the sprint backlog.

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.

Having the time for testing take too long to complete in 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.

Does frequent spill-over mean we should extend our sprint to 4 weeks from 2 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, go here. 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, go here.

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, check out The Benefits of BDD/ATDD.

If you are looking for Scrum training that has integrated test-first methods, go here.

We Have Difficulty Getting Cross-Functional Teams (Scrum/APM)

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.