Committing to a date in a product release environment

Session Notes

After our presentation and simulation, which we hope you all found interesting, we ended the session with an interesting Fish-bowl discussion.

Here is list of the issues we tackled and a summary of the ideas that came out of the discussion.

The list is too long to make decent estimates : it takes quite some time to make an estimate and there are too many items. How can this be improved?

  • Limit the list, prioritize it and add some requirements later
  • The person asking too many requirements should feel the "pain"
  • Estimate the value of the requirements to aid the prioritization
  • Let an accountant estimate the value of the requirements
  • Limit the time used for estimating
  • Make the cost of estimating visible, use a Kanban board to give visibility on how much is already being estimated
  • Plan in the estimation work
  • The product owner should filter the list based on the value of the requirements

If you decide to divide a cornerstone in parts : how is this best done? Horizontally of vertically?

  • It depends on the project
  • Horizontal
    • + easy to distribute , split up the work in parallel
    • - you need a clean design before starting
    • - takes longer to test end-2-end
  • Vertical
    • + there is always one part extra working
  • Do a combination of both Horizontal and Vertical
  • Have one team doing the integration while other teams focus on their area of expertise
  • In the session Multidimensional Planning, all secrets around this subject were reveiled
  • An interesting book around this issue : Scrum in the enterprise (Schwaber)

How can we make clear that prioritization would be more beneficial if done early rather than later?

  • "Waste" Not prioritizing early sometimes results in waste : work is started on some requirements but they did not make it into the release 
  • Make a "Fuck up" chart showing all the waste
  • Make the cost of estimating explicit
  • Work on releases in sequence instead of overlapping
  • Do not start on requirements before the priorities are decided. If you do start this will hide the problem

What about small releases?

  • Customers are not eager to take in new releases because it gives them extra risk and validation work when taking in the new release
  • The Service point of view (few big releases) and Development point of view (many small releases) are often opposite of each other
  • Having small releases reduces the need to maintain bugfixes over different releases (the one in the field, the upcoming release, ...)
  • Make upgrades easier to make small releases possible
  • Go even further: pushed automatic upgrades
  • Long periods of time (e.g. 1 year) between each release makes it difficult to decide on the content of the release. Each client will want to have all its requirements in the upcoming release. Otherwise they might have to wait too long.