Jordan Job

Professional Scrum Trainer at Scrum.org, software developer, guitarist, aerial RC pilot, photographer, constant learner, and more

  • Home
  • About Me
  • Scrum

Connect

  • Instagram
  • LinkedIn
  • Twitter
  • YouTube

Your Effort Is Not My Effort

April 25, 2015 By Jordan Job Leave a Comment

When estimating the size of work in Agile software development, story points, which are an abstract, relative measurement, are often used. Mature agile estimators will tell you that story points equal the effort required to complete the work plus a few other factors, such as complexity, risk, and uncertainty.

Sometimes effort is misinterpreted and misused as personalized effort rather than abstract effort. Personalized effort takes into account team composition, experience, and skills. Abstract effort does not. Estimating using personalized effort causes estimates to be inherently tied to the people estimating the work, but what we want is estimates that are independent of the people estimating the work because otherwise the work will need to be re-estimated every time the team’s composition or skills change.

In a recent blog post, Mike Cohn, author of Agile Estimation and Planning, revisited story points to clear up some misconceptions that have arisen in recent years. In that post, Mike used the example of “walking points” to describe estimating effort:

Suppose you and I are to walk to a building. We agree that it will take one walking point to get there. That doesn’t mean one minute, one mile or even one kilometer. We just call it one walking point. We could have called it 2, 5, 10 or a million, but let’s call it 1.

What’s nice about calling this one walking point is that you and I can agree on that estimate, even though you are going to walk there while I hobble over there on crutches. Clearly you can get there much faster than I can; yet using walking points, we can agree to call it one point.

– Mike Cohn in the Mountain Goat Software Blog

The principle is that estimated effort should be abstract and not personalized. Someone caught on to this and asked Mike what should happen to effort if a team becomes better at something over time:

Imagine a team with 3 developers that has the job to generate a website and there are two different user stories that both require a small form with 3 input fields and a submit button. The stories a pretty much the same, except that one of this forms has to be implemented in the beginning of the project, while appears quite some time later.

At the beginning the team is kind of new to the technology used and therefore estimates the user stories with 5 story points. That is fine for the first user story, but while progressing in the project the team learns and becomes better and the effort for implementing a form decreases.

– Rupert in the Mountain Goat Software Blog

Mike responded that the two stories should be the same amount of effort:

If I’m following your example in the question, perfectly then I would say that the estimates of the two (let’s call them identical) stories would be the same.”

– Mike Cohn in the Mountain Goat Software Blog

So what are the consequences of estimating using personalized effort instead of abstract effort?

  • Estimates are tied to the team’s composition, experience, tools, and skills at the time of estimation
  • A team’s velocity does not reflect the true learning and growth of the team because the personalized effort of doing the same thing over and over again typically decreases with experience and time

Why should you use abstract effort?

  • Estimates only require re-estimation when the relative size of the work changes
  • Velocity reflects the true growth of the team and allows you to show how a team has improved over time

Of course this all sounds good in theory, but how do you estimate using abstract effort and not personalized effort? When you estimate work, compare it to at least two other recent work items that have already been estimated. However, if you compare the work to older items, the team will be more likely to think the new work is less effort due to them now having more experience and skills than they had when they estimated the older work, so the key is to use recent items when doing relative estimation.

If you want to learn more about estimation in Agile, pick up a copy of Mike Cohn’s Agile Estimation and Planning.

Share this:

  • Click to share on LinkedIn (Opens in new window)
  • Click to share on Twitter (Opens in new window)
  • Click to share on Facebook (Opens in new window)
  • Click to email this to a friend (Opens in new window)
  • Click to print (Opens in new window)

Related

Filed Under: Agile Tagged With: Estimation, Story Points

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Search

Categories

  • Agile
  • Scrum
  • Uncategorized

Recent Posts

  • 5 things people get wrong with user stories
  • Your Agile adoption needs to be agile
  • 5 Things Management Must Do for Successful Agile Transformation

Tags

agile adoption Agile Basics agile certification Agile Coaching agile transformation Backlog Book Review change management Community of Practice Daily Scrum Estimation Facilitation Introversion leadership Lean Startup MBTI Organizational Disorders Personality Prioritization scaling Scrum Scrum Diagram Scrum Master scrummerfall Scrum training Scrum whys servant leadership Stand-Up Story Points Taylorism user stories velocity video

© 2019 JordanJob.me

loading Cancel
Post was not sent - check your email addresses!
Email check failed, please try again
Sorry, your blog cannot share posts by email.