Download to read offline
![inxin
inxin
• [in]frastructure for the [in]dependent
• Info at
– email@inxin.com
– http://www.inxin.com](https://image.slidesharecdn.com/dimensionalplanning-140204041009-phpapp02/85/Dimensional-planning-XPDays-2007-32-320.jpg)
Uploaded byinxin
Dimensional planning (XPDays 2007)
Dimensional Planning is a technique for making software development planning more predictable and adaptable while ensuring a shippable product is delivered on time. It involves adding new "dimensions" like dirt roads, cobblestone roads, and asphalted roads to different levels of a feature or feature group to provide alternatives. This allows for more flexibility in release and iteration planning compared to using a single backlog. Dimensions can be either explicit in planning or implicit based on a team's common language. The goal is to improve agility while still setting achievable goals.
Dimensional planning (XPDays 2007)
- 1.
- 2.
- 3. inxin Introduction • Not likeanything you’ve seen before! – Forget about other planning techniques (critical path, buffering, contingency, …) • Specialized for Software development – Especially OO development – No physical boundaries – No need to respect the natural order! No adoption of existing planning techniques!
- 4.
- 5. inxin Intent • Make planning –more Predictable – more Adaptable • The goal is to always have – a shippable product on time – that better fits the customer’s requirements
- 6. inxin Motivation • • • • Predictability vs Adaptability Anticipation Agilevs Rigid Anticipation Agile Planning too rigid
- 7. inxin Predictability vs Adaptability •Are they really inversely proportional?
- 8.
- 9. inxin Agile vs RigidPredictability • What kind of goals can we set without sacrificing Agility? • Is it possible that setting fixed goals can even improve Agility? • Are there different goals to choose from? • Do we need different techniques or is there a universal technique for different situations?
- 10. inxin Agile Planning tooRigid • At the release level (and above) • At the iteration level
- 11. inxin Release planning tooRigid • There are no alternatives – Just one backlog (one big pile of features) – No structure in the backlog (just a sequence) – No fallback
- 12.
- 13. inxin Applicability • Dimensionality isapplicable to – Feature Group level – Feature level • Dimensional planning is applicable to – Release planning (and beyond) – Iteration planning
- 14. inxin Structure • Add newdimensions – Dirt road – Cobblestone road – Asphalted road • to different levels – Feature group (alternate future) – Feature (alternate depth)
- 15.
- 16.
- 17.
- 18. inxin Alternate Futures • differentset of features per alternate future
- 19. inxin Alternate depths • Everyfeature has different depths
- 20.
- 21. inxin Consequences • Effects ofdimensional planning on – Release planning – Iteration planning
- 22.
- 23. inxin Iteration Planning • Differentplanning strategies – Dimensions in backlog – No dimensions in backlog • Same feature can show up in different iterations – But with a different dimension
- 24.
- 25.
- 26. inxin Implementation • Mr. Bikewants to get on the internet … • 2 Feature Groups – Enable E-Commerce – Support Customers online
- 27.
- 28.
- 29. inxin Related techniques • Partialsolutions • Buffering – Scope buffer (DSDM 70% rule) – Time buffer • Splitting user stories of mixed priority – These are new user stories
- 30. inxin Dimensional Planning Revisited •Explicit vs Implicit dimensional planning • Better fit for customer • Theory of Constraints
- 31. inxin Explicit vs ImplicitDimension • Implicit dimensions – Common language – Less overhead for planning – Especially useful in iteration planning • Team knows what a dirt/cobble/asphalted road for a feature looks like
- 32. inxin inxin • [in]frastructure forthe [in]dependent • Info at – email@inxin.com – http://www.inxin.com
Editor's Notes
- #4 Keep an open mind don’t be biased Agile methodologies borrow a lot from other more general theories e.g. Lean manufacturing and lean development Building classes can be done in random order (mostly)
- #5 We follow the method to describe software design patterns. A natural way to describe things. Later on , a workshop where we will apply this.
- #6 Bold statements: A better fit! always on time Predictability and Adaptabilityare not opposites
- #8 Normally when predictability goes up, adaptability goes down DP says that you can have predictability (to a certain extent) and that adaptability will even go up.
- #9 We are not alone We are part of a bigger whole (product release, marketing, …) Time is money
- #11 Planning is the Achilles heel of the agile movement We propose an alternative, and improvement By introducing dimensional planning
- #12 Especially when there are external dependencies No fallback = no plan B Release planning -> plan for alternative futures We’ll show later how these shortcomings are addressed in dimensional planning
- #13 Peddler = Leurder van deur tot deur
- #14 Feature Group Level = bunch of features that belong togethern (theme in xp, or an epic) Beyond release planning means: product, portfolio, and strategic planning (the onion)
- #16 Gets you from point A to point B But not with everything
- #17 Better for motorised (automated) transport
- #18 The customers request
- #19 Exclusive – pick one The customer decides which dimension she chooses A is everywhere B is not in the asphalted future What if something bad happens? You can reuse some features from different dimensions Not all is thrown away when you change your dimension
- #20 Incremental You must go from dirt to cobble to asphalt While on feature group level, you could pick one dimension.
- #23 First say what we see here 1, 2 and 3 are feature groups
- #24 Plan with dimension visible of not visible (but always present)
- #25 Default burndown chart.Advantage: can burn down more features
- #26 Advantage: invisible and easy to implement Guaranteed to have finished all your features at some level.
- #28 The customers must choose one alternate future
- #29 Depth is not always about functionality
- #30 Partial solutions: change your solution in the middle of something. Problaby a broken solution when things don’t go as planned. Buffering Splitting userstories: Data boundaries operational boundaries (crud) cross cutting concerns functional – non functional mixed priority