When we start out on a venture, of any kind, we hope things will run smoothly, we expect the ‘happy path’ / ‘sunny day’ scenario to be true. In designing our software, though, we know that we need to allow for alternate paths and exceptions. In the same way, when thinking about our projects, we should expect to be hit from left-field with surprises, and have ways of coping with those.
Did you ever play Jenga? It’s a challenging game of dexterity, patience, and brinkmanship — you start with a tower of blocks, 18 stories high, three blocks per story, then each player takes turns at removing a block from a lower level and placing it on top, until the tower becomes so unstable it topples over.
To ensure that a product is fit for market, as they draw close to a planned release date, many teams switch from feature development to stabilisation (or sometimes this is called hardening).
In a sense, we can liken stabilisation to playing Jenga in reverse.
How do you handle defects in your agile environment? Do you just work on them as you can; do you have a formal Kanban pull system; or do you size them alongside other work?
This article (first published on infoQ) explores why estimating is useful, why we use story points (and what they are), and the latest discussions around #NoEstimates.
Announcing the launch of Sophorum, a business agility service for business analysis, coaching, team leading, new product development, business design, education, etc.