Why write a review in 2013 about a book published in 2005?
Because, Mike Cohn's book, Agile Estimating and Planning is such a book that lays out the philosophy behind agile planning very beautifully, while leading the reader through day-to-day activities.1
And, as much as I tried to keep the review short, I did not succeed: There are so many nuggets of valuable information throughout the book that I justified making an elaborate review, and decided to publish the review in multiple sections. This post is the first of those.
If your agile development environment already has a set of tools predetermined, such as Rally Software or Jira Agile for example, your day-to-day approach to managing the development may already be somewhat predetermined by the software tool. However, whether you are in such a predetermined environment, or in a pristine environment with possibly no tools other than Microsoft Office, you'll need to recall the basics crisply, and Mike Cohn's book is one excellent reference source.
In Chapter 3, An Agile Approach, we see the author's concern on liberating the creativity of good software designers, and their uniqueness as individual human beings:
Chapter 5 introduces the concept of Estimating in Ideal Days, an alternative to story points for estimating the size of stories. Ideal Days is what it would take to complete a user story by the team if worked on uninterruptedly.
Fibonacci number sequence and binary number sequence are two alternatives estimation scales recommended for use in estimating the relative sizes of user stories in Chapter 6, Techniques for Estimating. This chapter also introduces the concept of epic user stories that comprise of simpler user stories that can be considered as being part of the epic, and themes that are a useful collection of user stories not related in any causal manner, but as a thematic collection.
In Chapter 7, Re-Estimating, considerations for when and how to produce re-estimations of story points are examined while noting that, in many cases, the use of velocity in determining the speed of execution obviates the need for re-estimating.
Chapter 10 on Financial Prioritization describes, in considerable detail, the various concepts of Net Present Value (NPV), Internal Rate of Return (IRR), Payback Period and Discounted Payback Period.
Prioritizing Desirability is Chapter 11's content. It elaborates on the Kano model of customer satisfaction that separates features into three categories:
Considerable discussion of assessing themes in the Kano model follows in the chapter.
Splitting User Stories is the topic of Chapter 12. It does take some practice to define user stories in a complete, meaningful, way: Ideally, we want a user story completely implementable in a single iteration or sprint. Splitting user stories along data boundaries, along operational boundaries, based on CRUD operations, by removing cross-cutting concerns, by separating performance concerns, by separating priority considerations are all discussed in this chapter. An important concern that has been quite frequently written about in the web is: Horizontal and Vertical User Stories - Slicing the Cake.
Because, Mike Cohn's book, Agile Estimating and Planning is such a book that lays out the philosophy behind agile planning very beautifully, while leading the reader through day-to-day activities.1
And, as much as I tried to keep the review short, I did not succeed: There are so many nuggets of valuable information throughout the book that I justified making an elaborate review, and decided to publish the review in multiple sections. This post is the first of those.
If your agile development environment already has a set of tools predetermined, such as Rally Software or Jira Agile for example, your day-to-day approach to managing the development may already be somewhat predetermined by the software tool. However, whether you are in such a predetermined environment, or in a pristine environment with possibly no tools other than Microsoft Office, you'll need to recall the basics crisply, and Mike Cohn's book is one excellent reference source.
Part I. The Problem and the Goal
Part I starts with Chapter 1 on The Purpose of Planning by talking about the importance, and purpose, of planning:"Estimating and planning are not just about determining an appropriate deadline or schedule. Planning—especially an ongoing iterative approach to planning—is a quest for value." (Kindle Locations 573-574).Chapter 2 on Why Planning Fails is a good set of observations on how traditional approaches tend to fail:
"A critical problem with traditional approaches to planning is that they focus on the completion of activities rather than delivery of features. ... A first problem with activity-based planning is that customers get no value from the completion of activities. Features are the unit of customer value. Planning should, therefore, be at the level of features, not activities." (Kindle Locations 698-702)
In Chapter 3, An Agile Approach, we see the author's concern on liberating the creativity of good software designers, and their uniqueness as individual human beings:
"Great software is made by great individuals, and as an industry we have tried too long with too little success to define a development process that relegates individuals to replaceable cogs in the machinery. Agile processes acknowledge the unique strengths (and weaknesses) of individuals and capitalize on these rather than attempting to make everyone homogeneous." (Kindle Locations 843-845)And, the emphasis on delivering something of business value on each iteration, or sprint, is very well laid out by making use of the concept of Conditions of Satisfaction, both at the story level and at the Release level. The discussion on release planning that proceeds hierarchically from the Release, through Iteration or Sprint, and the Daily scrum, has business value reverberating in every step. (Although the hierarchy can be extended with increasing scope, as Figure 3.1 notes in the The Planning Onion, from the Release, through Product, Portfolio, and Strategy, the book's focus is on the lower levels of the hierarchy: Release, Iteration, Daily Scrum; you can see the planning onion diagram as the slide #8 in Mike Cohn's deck on Agile Planning and Project Management).
Part II. Estimating Size
Estimating Size with Story Points, Chapter 4, takes the reader through the concept of Story Points."... a story-point estimate is an amalgamation of the amount of effort involved in developing the feature, the complexity of developing it, the risk inherent in it, and so on." (Kindle Locations 1084-1085).The concept of story points is well explained, removing doubts as to whether such estimates on incompletely defined stories would even work:
"... However, we need to associate an estimate with each story, even those that are incompletely defined." (Kindle Locations 1107-1108)And, there is persistent emphasis on why the story points idea is valuable because it helps to separate the estimation of effort from the estimation of duration, by using the concept of velocity of the team.
"To understand how estimating in unitless story points can possibly work, it is necessary to introduce a new concept: velocity." (Kindle Location 1115)
"If we know the team's velocity we can derive [release story-point] size by velocity to arrive at an estimated number of iterations." (Kindle Locations 1126-1127)There is even assurance that this method works well:
"The beauty of a points-based approach to estimating is that planning errors are self-correcting because of the application of velocity." (Kindle Locations 1137-1138).And, the example of house painting, where only the relative dimensions of the various rooms are available, is very illuminating on this separation concept.
Chapter 5 introduces the concept of Estimating in Ideal Days, an alternative to story points for estimating the size of stories. Ideal Days is what it would take to complete a user story by the team if worked on uninterruptedly.
Fibonacci number sequence and binary number sequence are two alternatives estimation scales recommended for use in estimating the relative sizes of user stories in Chapter 6, Techniques for Estimating. This chapter also introduces the concept of epic user stories that comprise of simpler user stories that can be considered as being part of the epic, and themes that are a useful collection of user stories not related in any causal manner, but as a thematic collection.
In Chapter 7, Re-Estimating, considerations for when and how to produce re-estimations of story points are examined while noting that, in many cases, the use of velocity in determining the speed of execution obviates the need for re-estimating.
"... velocity is the great equalizer. Because the estimate for each feature is made relative to the estimates for other features, it does not matter if our estimates are correct, a little incorrect, or a lot incorrect. What matters is that they are consistent." (Kindle Locations 1510-1512).And, there is this reassuring wisdom on not to get excessively concerned about re-estimating:
"Do not become overly concerned with the need to re-estimate. Whenever the team feels one or more stories are misestimated relative to other stories, re-estimate as few stories as possible to bring the relative estimates back in line." (Kindle Locations 1576-1578).Having introduced both story points and ideal days as metrics of story size, Chapter 8, Choosing between Story Points and Ideal Days, discusses pros and cons of using both and concludes with the author's recommendation:
"You should re-estimate only when your opinion of the relative size of one or more stories has changed." (Kindle Location 1581).
"My preference is for story points." (Kindle Location 1678).
Part III. Planning for Value
Chapter 9 dwells on Prioritizing Themes based on several factors:- Financial value
- Cost of development
- Amount and significance of new learning and
- The amount of risk removed
Chapter 10 on Financial Prioritization describes, in considerable detail, the various concepts of Net Present Value (NPV), Internal Rate of Return (IRR), Payback Period and Discounted Payback Period.
Prioritizing Desirability is Chapter 11's content. It elaborates on the Kano model of customer satisfaction that separates features into three categories:
- Threshold, or must-have, features
- Linear features
- Exciters and delighters
"Threshold features are those that must be present in the product for it to be successful. They are often referred to as must-have features. ... A linear feature is one for which “the more, the better” holds true. ... Finally, exciters and delighters are those features that provide great satisfaction, often adding a price premium to a product. However, the lack of an exciter or delighter will not decrease customer satisfaction below neutral. ..." (Kindle Locations 2195-2207).
Splitting User Stories is the topic of Chapter 12. It does take some practice to define user stories in a complete, meaningful, way: Ideally, we want a user story completely implementable in a single iteration or sprint. Splitting user stories along data boundaries, along operational boundaries, based on CRUD operations, by removing cross-cutting concerns, by separating performance concerns, by separating priority considerations are all discussed in this chapter. An important concern that has been quite frequently written about in the web is: Horizontal and Vertical User Stories - Slicing the Cake.
... to be continued in the next post
No comments:
Post a Comment