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.
Extensive travel? What do you mean?
In my experience, the planning of sprints must be driven by dedicated resources, preferably by the company business analysts in their role as product owners. This does not mean that developers will not be an integral part of the planning though, it just means that the planning must be driven by product owners and that the product owners are responsible for the existance of estimatable stories when sprint planning day has come. Sprint planning is a process that should run parallell to the sprints. The same way that scrum teams deliver working code to the product owners, the product owners should deliver estimatable stories to the scrum teams. In order to do this, scrum team members must be involved, which ofcourse will be an impediment for the scrum team but unfortunatly there is no way around this.
My option would be the following:
Make the product owner responsible for writing sprint stories, that is, responsible for figuring out what to make of the product (sounds like typical PO stuff right, shouldn’t be to hard to accept). Let some of the team members spend, say 30% of their time, helping the product owner with story writing. The team members that work part time with the product owner and part time with the team will lose some of their productivity but that loss will be countered by the much more effective planning you will get.