In Toyota Production System (TPS) action takes place through the Plan-Do-Check-Act-Cycle

If we relate this to Scrum we see a lot of emphasis on the Do, Check, Act part. But not as much on the plan part. Planning is usually explained as a an activity that takes place on sprint planning day where both team and product owner are participating.

However, how do we deal with situations like:

• stories that require a multi team effort
• interfaces to third party systems

..and given a definition of  done "running in production" are we answering questions like:

• are we implementing the right solution to our problem?
• is our delivery useful to our recipients?
• have we got access to necessary resources?
• can we test? can we deploy?

Basically we need continuously run a thought process in the sprint before we do the implementation. Typically a development team spend around 20% of their time planning for their implementation (Mary Poppendieck).

The deliverable for the thought process is "story has business value and is estimatable"
So how do we go about?

Option 1: Use scrum master as an analyst
Appoint the Scrum master as the responsible person for dealing with forward thinking.

Pro’s:

• SM is already a contact point
• He does not suffer as much from interupt control as other team members

Con’s

• Not always the correct technical person for solutions
• Team can feel overrun

Option 2: Use an external analyst
Get a dedicated analyst in the team that always looks forward.

Pro’s:

• Releaves team from communication stress

Con’s

• Adds an extra handover step (waste)
• Needs to be a superb communicator with team.
• Analysts tend to lean over to business focus
• Communication issues remain hidden

Option 3: Assign a "look ahead" story for each sprint
Insert a story which makes next sprint stories estimatable.
Team can pick tasks from this story in same way as on normal stories.

Pro’s:

• Team can choose among the stories in normal scrum way
• Communication issues are surfaced
• Bonding to outside parties is preserved in team

Con’s

• Product owner needs to have a forward vision
• Team members might need training in communication skills
• Implementation might suffer if extensive travel is required

My personal preference is with the option #3. But I have also seen option #1working in Scrum teams. The bottom line is that you need to think this through or you might end up building software that does not deliver intended business value.