Desserts

Just enough up-front design (visual & architectural)

Doing too much upfront design doesn’t go well with the agile way of working. It usually produces a lot of waste: design work that turns out not to be needed later on. Regarding visual design, we have good experience with having the global style designed upfront, and designing details one sprint (or less) ahead of development. Regarding architectural design, there is good experience with the approach of emergent design (which requires continuous refactoring). However, if the team identifies a number of aspects for which they prefer some upfront design, this will be part of the co-preparation phase. In all cases, it is up to the team to choose the preferred approach, and also to change it along the way, based on experience.

Proof of Concept

Certain technical uncertainties identified during co-preparation[1] can prevent a team from giving estimations, or give too much uncertainty on time and budget for the customer. In those cases, we choose to execute a proof of concept. The purpose of a proof of concept is to gain the knowledge necessary to reduce the risk of a technical approach, better understand a requirement, or increase the reliability of a story estimate.

Notes

  1. Co-preparation - The Product Owner (PO) meets the Team with their technical skills to define the best solution for the business case challenges. Best ideas arise in offsite meeting(s) in a relaxed and inspiring atmosphere. Various techniques are used to explore possibilities and to discover business values and ways to mitigate risks.