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.
Challenges with completing a sprint
Agile Product Management and Writing Stories
Organization of people
Want to be able to ask your own questions and get answers from experts? Check out our Community Bundle.
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:
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:
So bottom line advice is:
Using Test-First Methods can also help this problem as it makes for smaller, well-defined stories.
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 testing lagging behind coding is an indication of one or more of several problems:
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.
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).
If you are looking for Scrum training that has integrated test-first methods, go here.
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