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.
- SM is already a contact point
- He does not suffer as much from interupt control as other team members
- 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.
- Releaves team from communication stress
- 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.
- Team can choose among the stories in normal scrum way
- Communication issues are surfaced
- Bonding to outside parties is preserved in team
- 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.