STANWOOD insights

Book review: Agile Estimating and Planning - Mike Cohn

Aug 13, 2019 10:50:01 AM / by Hannes Kleist

Our head of catering Hannes, reviews his favorite books.

This week Hannes read the a deeply insightful book about Scrum planning.

Stanwood is going scrum and planning is one of the more complex topics - especially for an agency. 

This book walks the reader through the process.

Part I. The Problem and the Goal

This means that work is typically prioritized and sequenced for the convenience of the development team.

Part II. Estimating Size

The beauty of this is that estimating in story points completely separates the estimation of effort from the estimation of duration.

This level of focus on the individual roles on a team shifts team thinking away from the “we’re all in this together” mentality we’d like to exist on an agile team.

Some teams prefer to work with larger numbers, such as 10, 20, 30, 50, and 100. This is fine, because these are also within a single

Part III. Planning for Value

Separate features into three categories: 

  • Threshold, or must-have, features
  • Linear features
  • Exciters and delighters

A user story should be split when it is too large to fit within a single iteration.

The best ways to split a large user story is by the data that will be supported.

In some cases a large story can be made much smaller by removing the handling of exceptional or error conditions from the main story.

Split large stories based on the operations that are performed within the story. Split a story along the boundaries of the common CRUD operations—Create, Read, Update, and Delete.

Single iteration, develop the screens in one iteration and add support for user-specific privileges in a later iteration.

“Make it work, then make it faster.” Consider splitting a large story by separating the functional and nonfunctional aspects into separate stories.

The story can be split by looking for low-priority elements.
Sometimes, we come across a feature that is difficult to split. In these cases, it is tempting to split the feature into its constituent tasks. That may mean delivering a partial user interface, a partial middle tier, and a partial database. Don’t split a large story into tasks. Instead, try to find a way to fire a tracer bullet through the story.

Once you’ve split a story and have it at an appropriate size, don’t make things worse by adding work to the story.

Avoid making things worse by adding related changes to an appropriately sized feature unless the related changes are of equivalent priority.

Splitting features such that each can be done in two to five days or so is appropriate.

Part IV. Scheduling

While planning an iteration, tasks are not allocated to specific individuals. Projects do best when they foster a “we’re all in this together” attitude.

An agile team has the goal of fixing all bugs in the iteration in which they are discovered.

This fits with reports that individuals spend 55% (Ganssle 2004) to 70% (Boehm 1981) of their time on project activities.

Part V. Tracking and Communicating

Do not track individual velocity.

We want all communication, but especially communication about estimates and plans, to be frequent, honest, and two-way.

Product owner has been telling them artificial dates, they will no longer trust her.

Buy the book here