Should I use hours to estimate my tasks in Scrum?

My new recommended “starter” “complementary practice” for new Scrum teams is to simply create tasks and use the “number of tasks remaining” for a burndown.  (I also usually recommend that they try to make it such that the vast majority of their tasks are roughly 1 day or less) I encourage them more to focus on PRI (potentially releasable increments), Sprint Goals, and achieving a moderately consistent level of skill at meeting their Sprint forecasts (used to be called “Sprint commitment,” it’s been re-named in the Scrum Guide).  I also caution heavily against trying to achieve perfect forecast accuracy as that’s a fool’s errand in complex domains.

Using hours for tasks can lead down some really bad roads, most notably:  Former PM’s turned SM’s and other organizational members who try to apply PMI tactics (100% utilization, tracking actuals, etc) tactics to complex software development.  By preferring “sticking to the plan” over “responding to change”, they are completely violating Agile and Scrum.

This same bad road can also lead companies into think that “schedule/scope/cost” is an optimum model for software development.  As far as I’m concerned, schedule/scope/cost is a dead, failed model for software.

Now, using hours for tasks doesn’t have to lead down those bad roads — but in my experiences, they usually do.  Let’s not forget, Scrum used to require hours for task estimation, many years ago, but the Scrum experiences of the wider community over 20 years has spoken on the topic — hours is not always optimum.  I would go farther than that and say, at the Sprint task level, it’s usually NOT optimum.

Given the above, I’ll leave it as an exercise to others to describe where using task hours might not lead down those bad roads.

_____
Charles Bradley
Professional Scrum Trainer
Scrum Coach-in-Chief

http://ScrumCrazy.com

New Courses from ScrumCrazy.com:

  • Scrum For Executives
  • Agile Requirements: Product Owner and Team Collaboration Techniques
  • Scrum Product Owner: Techniques for Success
  • Evidence Based Management for Software Organizations(TM)
    • Class for Software Development Managers and Executives

If you’re interested in any of our classes, training, or coaching services, feel free to contact us.

Scrum of Scrums is an event *of* the Development Team, *by* the Development Teams, and *for* the Development Teams!

Hello ScrumCrazy readers,

I’m proud to announce that my article on the “Scrum of Scrums” practice got posted on Scrum.org.

In the article I give some advice on excellence in execution of the Scrum of Scrums practice, and how the Scrum of Scrums has been misinterpreted my many to be a status meeting. It’s an event of the Development Teams, by the Development Teams, and for the Development Teams!

Please give it a look and give me feedback here or there. Feedback welcome!

I Recommend the New Book _Scrum Shortcuts…_ by Ilan Goldstein

I came upon Ilan’s new book, Scrum Shortcuts Without Cutting Corners,  by seeing his great blog posts first, then I actually offered to review his book.  What he didn’t know, is that on the rare occasion I take the time to review a book (unpaid), I usually look at the first couple of chapters they give me to review before deciding whether I’ll actually follow up and review more of it or not.  Ilan’s book was great, so I offered to do some more reviewing for him before he published it.

There are some recent books out on the Scrum Master role, and I don’t care for a lot of them.  Ilan’s book is one I wholeheartedly endorse.  It’s short, it’s easily digestable, and packed with practical advice.  Like he says in the book, it’s not a prescription — it’s simply a list of possible strategies to play Scrum with.

Ilan’s book is in the Mike Cohn series, and even though I’m certified as a trainer through a different organization (and don’t always agree with anything 100% these days), I really like the Mike Cohn series a lot.  It’s a quality series of books, among a larger field of books that I mostly don’t recommend.

I’m gladly adding Ilan’s book to my list of favorite Scrum and Agile resources.  I recommend you pick up a copy and do the same!

(I receive no financial benefit for writing this review)

May the Sprint be with you… and… Scrum On!

Scrum and Agile Adoption: Backsliding into Waterfall Habits

It’s very common, when an organization is in the Shu level of learning Agile or Scrum, for it to fall into old, bad, waterfall habits.  Today I’d like to talk about two bad waterfall habits:  tracking so called ‘individual velocity,’ and tracking actual effort expended on a task or story.

First, tracking some sort of metric like “individual velocity” is probably an excellent way to completely sabotage your project/product and it’s also a great way to kill your Agile adoption.  A key concept in the Agile Manifesto principles, as well as in Scrum, is team work and “self-organizing” teams.  Self organization is generally the ability for a team to create and execute their own plan of work(Sprint Backlog), as well as decide “How” to do their work.  Whenever there is a single entity (individual on or off the team, department, etc) who strongly influences or makes unilateral decisions for how a team works, there is, by definition, no self organization.  Tracking individual velocity, or any similar “individual incentive” (this can include raises, performance reviews, awards, etc) does not encourage team work at all.  In his book, Agile Estimating and Planning, Mike Cohn says it this way:

“If I am forced to choose between finishing a story on my own and helping someone else, what incentive does measuring individual velocity give me?  Individuals should be given every incentive possible to work as a team. If the team’s throughput is increased by my helping someone else, that’s what I should do. Team velocity matters; individual velocity doesn’t. It’s not even a metric of passing interest.”

Tracking actual effort expended is another really bad waterfall habit.  Tracking estimates and actuals is just another example of where Common Project Management Metrics Doom IT Departments to Failure.  Mike Cohn, an Agile and Scrum thought leader, and a former project manager himself, says this about tracking estimates and actuals:

“On a project, it is far more useful to know how much remains to be done rather than how much has been done. Further, tracking effort expended and comparing it with estimated effort can lead to ‘evaluation apprehension’ (Sanders 1984). When estimators are apprehensive about providing an estimate, the familiar ‘fight or flight’ instinct kicks in, and estimators rely more on instinct than on analytical thought (Jørgensen 2004).

Tracking effort expended in an effort to improve estimate accuracy is a very fine line. It can work (Lederer and Prasad 1998; Weinberg and Schulman 1974). However, the project manager or whoever is doing the tracking must be very careful to avoid putting significant evaluation pressure on the estimators, as doing so could result in estimates that are worse rather than better.

Additionally, keep in mind that variability is a part of every estimate. No matter how much effort is put into improving estimates, a team will never be able to estimate perfectly. Evidence of this is no further away than your morning commute to work. There is an inherent amount of variability in your commute regardless of how you travel, how far you must go, and where you live. If you drive to work, no amount of driving skill will eliminate this variability.”

In a later post on the ScrumDevelopment Yahoo Group, Mike summarizes it this way:

” I’d say you shouldn’t do it because it doesn’t add value commensurate with its cost. Don’t argue with your bosses that it ‘adds no value’ because
comparing what you originally thought a task would take with what it did take can help make you a better estimator.

But, it can be time-consuming to track actuals, especially for a full team where some on the team are probably already decent estimators.

Because Scrum already has solid mechanisms for monitoring whether all the work gets done in a sprint (high team commitment, daily burndown charts, daily scrum, and so on), Scrum does not have the same reliance on early and accurating estimating that a predictive or waterfall approach does.

So–the cost to gather actuals is the same in Scrum or waterfall. The benefit in Scrum is greatly reduced.”

So, be very careful when backsliding into old waterfall habits.  It usually happens in small doses, which is why many Shu level adoptions don’t notice it, especially if they don’t have a skilled Scrum Coach or highly experienced Scrum Master around.  The other thing to keep in mind is that, even if you do have someone skilled around, this old adage still applies:  “You can lead a horse to water, but you can’t make ‘em drink.”

What kind of backsliding into old waterfall habits have you seen?  What do you suggest be done about them?  Sound off in the comments below!

Great 2 Minute Video on the Product Owner Role in Scrum

SSW of Australia has just put out a great two minute video on the role of the Product Owner in Scrum.

Check it out here(might take a minute to load):  http://tv.ssw.com/3244/what-is-a-product-owner

I’ve added it as #4 under Scrum on the ScrumCrazy.com’s list of preferred Scrum resources.

New and Improved User Story Lifeycle Diagram — Free Creative Commons PDF download!

I had a designer friend update my User Story Lifecycle diagram, and she did a fantastic job!  You can download the PDF here:  http://www.scrumcrazy.com/lifecycle

New and Improved Diagram:

UserStoryLifeCycle_final_lg

The Older Diagram(also still available at the above link):

UserStoryLifecyclexm

Other Good User Story Links

Daily Scrum Patterns: The Sprint Backlog at the Daily Scrum

This blog post is part of a series of blog posts on Daily Scrum patterns.  For some background, you might find it useful to read my previous article on a simple Scrum Patterns framework.  Daily Scrum Patterns fall under the category of “Scrum Technique Patterns”, as introduced in that article.

Today we’ll talk about “Obstacle Resolution Patterns”

Notes:

“The Sprint Backlog at the Daily Scrum” Patterns

While it’s a popular and proven practice to <View the Sprint Backlog at the Daily Scrum>, it’s a controversial practice to <Update the Sprint Backlog at the Daily Scrum>, as the updating can detract from the true objectives and focus of the Daily Scrum in some situations.

Also, don’t forget to be creative and <Create Your Own Pattern>, and don’t ever hesitate to use a technique that is not described by a documented pattern.

The Sprint Backlog at the Daily Scrum Patterns:

Follow

Get every new post delivered to your Inbox.

Join 286 other followers

%d bloggers like this: