As a result of my post on Scrum Teams that are “In the Flow”, I’ve had some conversations about teams that are NOT in the flow.  What are the characteristics of a team that is not in the flow for a sprint?  Here are some:

• Vague goals
• Poor quality backlog for the sprint (another way of saying the first item)
• External distractions like bug fixing and other planning
• Dependencies within the sprint that hold up others
• Poor movement of tasks between resources (i.e. poor collaboration)
• Poor transition between sprints

While the Scrum Master is ultimately responsible for enabling the team to run smoothly, everyone on the team also has responsibility for the state of the team and its success.  Self managed teams find ways to get things done against long odds; more creativity for problem solving comes from many heads than just the leader(s) attempting to solve the problem.

That said, one of the more difficult challenges is poor quality backlog entering the sprint.  If the team doesn’t understand what it is trying to accomplish, it’s not going to be able to get on the same page to get in the flow for the sprint.  I have three suggestions for dealing with a poor sprint goal:

• Describe the goal in terms of the demo that the team will give at the end of the sprint.
• Describe the goal in terms of the tests that will need to pass to verify that the goal was met.
• If you can do neither of the above, run a short sprint with the goal of better defining the goal.  The Product Owner is a critical part of this, but the team can help him by prototyping, brainstorming, or other tasks.

I’ve used shorter sprints on multiple occasions in the past year and they have been helpful.  Plan for the length of time that you can competently plan for – common sense rules again!