Tag Archives: sprint

Doing 45 minute sprint planning

Posted on by

  1. Hand out the epics (we typically have 2-3 per week)
  2. Assign one senior and one junior for each epic
  3. Forming a group per epic by letting rest of team choose from interest, but allow no larger than four members in per group
  4. Let each epic team do breakdown and size estimation
  5. Swap epic between the teams and review (we typically let one person stay and explain)

45min sprint planning

This has worked out really well. The energy and intensity of the discussions was raised significally. So far we have managed to keep our 45 time window almost every time. .A bonus is that the review almost every time have results in an changed task or a reestimation.  Thereby showing the value of a second opinion with an outside angle.

Planning ahead in Scrum

Posted on by

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

Plan-Do-Check-Act

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).

Thinking ahead
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.

Prediction Markets och Scrum Sprint Planning

Posted on by

Jag har vagt känt till begreppet Prediction Markets, där man sammanfattar många individers förutspåelser om aktiekurser, vilken teknik som kommer att lyckas och misslyckas, och andra svåra frågor där enskilda individers kunskap ofta inte är tllräcklig, eller något man generellt sett inte litar på. Vem litar på enskilda aktieanalytiker, till exempel.

Stötte nyligen på en artikel i ämnet som sammanfattar ett event i Silicon Valley om just detta ämne, anordnat av Yahoo. Det visar sig vara ganska mycket på gång, bland annat finns det ett open source ramverk skrivet i Java med namnet Zocalo. En kille från Microsoft berättade att man använt tekniken för att förutspå testplanering, där det visat sig att man på detta sätt förutspått att planen inte skulle hålla tidsramen. Och då slog det mig att man skulle kunna använda anonyma formulär på detta sätt för att fråga medlemmarna i ett Scrum team om de tror på tidsramarna för en sprint. Kanske tror man inte på tidsplanen, men vill inte säga något om det för att inte verka negativ eller långsam. Får man svara på detta anonymt, så kanske det kollektiva svaret blir bättre än det som framkommer under mötet då tidsplanen tas fram?