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.

My Preferred Agile, Scrum, and XP Resources

If you’re printing this post, it can be found online at: http://www.scrumcrazy.com/My+Preferred+Agile%2C+Scrum%2C+and+XP+Resources

A friend recently asked me this question:

What would you recommend in terms of the best book(s) to learn about Agile (Scrum) with XP practices? That is, if you had a team of developers who were newbies to Agile, Scrum, and XP, what books/articles would you give them to bring them up to speed on what they should be doing and how they should be doing it?

This question from my friend is a very tricky one, in that it is very broad and generic, and my friend gave me no extra team or organizational context to go on, so about all I can do is give a generic answer, and that is what I’ve done below. If you’re looking to combine Scrum with XP practices, be sure and see Kniberg’s book under “Scrum” below.

Don’t have time to read all of these? Well then, read the first couple from each category, and then continue working your way down each list.

My Preferred Resources

All are in order of my personal preference in each category.


Scrum

  1. The Scrum Guide (Must read for all)
  2. Deemer, et al. “The Scrum Primer”
  3. Cohn’s _Agile Estimating and Planning_ (Must read for Scrum Masters)
  4. Pichler’s _Agile Product Management…_ (Must read for Product Owners)
  5. Cohn’s _Succeeding With Agile…_ (Must read for Scrum Masters once they have a few Sprints under their belts)
  6. Kniberg’s _Scrum and XP From the Trenches_ (Note that there is a free PDF download of this book if you register with InfoQ – something I recommend anyway)
  7. Derby/Larsen’s _Agile Retrospectives_

XP (Extreme Programming)

  1. Jeffries’ “What is Extreme Programming?”
  2. Jeffries’ _Extreme Programming Installed_
  3. Koskela’s _Test Driven…_
  4. Martin’s _Clean Code_
  5. Feathers’ _Working Effectively With Legacy Code_
  6. “The Rules of Extreme Programming”
  7. Wiki entry on XP Practices

Agile/XP Testing

  1. Summary of Lisa Crispin’s Presentation to Agile Denver on Test Automation
  2. Cripin’s “Using the Agile Testing Quadrants”
  3. Crispin/Gregory’s _Agile Testing_
  4. Crispin/House’s _Testing Extreme Programming_
  5. Cohn’s “The Forgotten Layer of the Test Automation Pyramid”
  6. Osherove’s _The Art of Unit Testing_

User Stories (which originated in XP)

  1. My “User Story Basics” article and all of the links at the bottom of that article
  2. Cohn’s _User Stories Applied_
  3. Cohn’s _Agile Estimating and Planning…_ (Chapter 12: Splitting User Stories)
  4. Lawrence’s “Patterns for Splitting User Stories”

Special Agile Topics (if applicable)

  1. Deemer’s “The Distributed Scrum Primer” (If some of all your team is remotely distributed)
  2. My article entitled “The Role of Managers In Scrum” and all of the links at the bottom of that article
  3. Larman/Vodde’s _Scaling Lean Agile…_ (If your Agile transformation involves a very large organization)

One Way to Handle Bugs and Production Support in Scrum

Dear ScrumCrazy readers,

I need your help. I’m working on a Scrum strategy for handling bugs and production support on a Scrum team. This is the first draft of the chart below. I already have a couple of changes I would like to make, so I’d appreciate it if anyone could provide feedback on the chart below. Just hit the “comment” button below or email me directly with your advice. Thanks!

The Scrum Guide doesn’t directly address how to incorporate production support and bugs into your Scrum implementation. As such, it is left up to the implementers to decide how to handle it. The strategy(chart) below is one I’ve developed as a result of coaching teams that are new to Scrum.

I hope you don’t need the chart. I’ll say it again. I hope you don’t need the chart below. I hope that you have so few bugs and productions support issues arise, that you don’t even really need to worry about classifying bugs or coming up with a technique to handle production support. But, for the teams that need some guidance on how to incorporate these issues into their Scrum implementation, see below for one way to approach it. I also feel compelled to say that if you find yourself needing this strategy/chart often, you probably have some serious root cause analysis and retrospecting to do on these occurrences.

Why I include “Bradley” in the name.

Please be sure and read the “Preface” section on the chart below. There is an 8.5 X 11 PDF download below the image.

It’s a little difficult to see here on WordPress, so you might want to view it on my web site.

The Bradley Bug Chart
Download (8.5 X 11 PDF):  http://www.scrumcrazy.com/file/view/ScrumBug8x5x11.pdf

So, what did ya think?  Just hit the “comment” button(or “Leave a Reply” form) below or email me directly with your advice.

I Mostly Hate Software for Managing Scrum Teams

Update February, 2012: I’m currently seeking my next engagement as a Scrum Coach or ScrumMaster, so please contact me (You can use the “About” tab above) if you know of an opportunity.

I often get asked to evaluate a particular Scrum tool or to compare the relatively value of one to another. To be honest, tool evaluation is not something I spend significant time on. Most teams I coach have little choice about which tool to use, so I usually just a) try to encourage them to use more manual techniques and b) help the team adapt the tool usage to their optimum performance/usage, which sometimes means no usage.

I hate the tools

Ok, hate is a strong word, but I’m generally anti-tool when it comes to managing Scrum artifacts and data. I strongly prefer more manual techniques (Scrum Boards, sticky notes, story cards, white boards, wikis, etc).

Reason 1: Tools often hurt more than they help. (Decreases Productivity)

The vast majority of the time I have seen Scrum teams extensively using a tool, it is wasteful or aids in creating poor habits. It’s pretty hard to justify spending money on a tool that decreases overall productivity. I’m amazed at how many companies do this. I also believe that most of these tools have a huge amount of bloat in them, and thus the bloated features either a) obscure the needed features or b) waste a lot of time with very little ROI in terms of value.

Reason 2: They usually encourage bad habits, or at least enable bad habits. (Decreases Transparency & Productivity)

  • Bad Habit # 1: The worst habit they encourage is that they often obscure transparency by hiding data inside the tool that has to be …started up, logged into, and menu driven to the point of wanted info. Transparency in Scrum is VERY important, which is why I favor more manual techniques. This obscurity is extremely widespread as it affects the product backlog and/or stories, sprint backlog tasking, teamwork, optimizing with a burndown chart or other sprint progress monitor, etc. Transparency aids in inspection and adaptation, so the converse is also true: obscurity detracts from inspection and adaptation and thus, detracts from the empirical nature of Scrum.
  • Bad Habit # 2: They discourage mis-use of good techniques. For instance, in many tools, there is no direct support for story tests/acceptance tests directly with the User Stories themselves. One tool at least allows some basic html formatting and tables so that you could put in some concrete examples like those that are encouraged by the “Specification By Example” technique. However, that tool’s HTML formatting is very clunky and far inferior to any decent wiki.
  • Bad Habit #3: Having a tool encourages double entry. I’ve seen teams where, because they were forced to use a tool but also wanted a good Scrum Board, had to do double entry of the same information. Giant waste of time.
  • Bad Habit #4: A tool encourages mis-use of metrics created by Scrum related data such as velocity. Many managers and executive types will try to do draw incorrect conclusions from data tracked in such a tool. Yet another giant waste of time. The managers and executive types should instead be focusing on whether the users of the system are getting value out of the features that are being provided. While some management has a responsibility to focus on productivity in software development, micro-analyzing the Scrum data is not a good way to do this.

Reason 3: The development team usually has the tool forced upon them, or usually has no choice but to use a particular tool. (Decreases Self Organization)

Besides the normal effects of top down mandates (poor adoption, minimal ROI, etc), the elephant in the room created by mandating tools is that it greatly harms self organization on a Scrum team. Mandating particular tools or tool usage is just another form of command and control management. To achieve Scrum’s benefits, self organization is absolutely vital, which means, when it comes to tools, the team should be able to make their own choices.  I want the team as a whole (and preferably not the ScrumMaster at all) to create, maintain, own, love, and care for their own artifacts.  Having said all of this, it’s perfectly acceptable for management types to try and organize company strategy around goals and timelines — I just don’t believe that Scrum software tools are a good way to do that.

In Conclusion…

There, I said it… I’m generally anti-tool for Scrum artifacts and data.

In a future blog post, I intend to talk a little about some special contexts in which I think tool usage is ok, and about my general views as to the kinds of tools that I like. Teams where multiple members are working mostly remote is one exception to my generally anti-tool stance. I’ll talk more about that in the future post.

Tips for Effective Backlog Grooming – Part 2

Tips for Effective Backlog Grooming

In my tips articles, I try to describe highly effective ways to fulfill the Scrum framework. The Scrum framework intentionally leaves holes that are opportunities for teams to fulfill the framework in the way that is best for a particular team’s circumstances. The Scrum Guide defines the Scrum framework, and my tips are in no way meant to define or re-define Scrum. My tips are based on my numerous Scrum coaching experiences, and I believe them to be consistent with the Scrum Guide.


Tip #1: Try to never schedule backlog grooming during the first or last 20% of the Sprint.

During the first 20% of the Sprint, the team is just getting started on this Sprint’s work, so you’ll want to give them some room to get a good start. During the last 20% of the Sprint, the team is working hard to get closure on the current sprint items, so that’s not really an ideal time to do it either. That middle 60% of the sprint is a good time to do backlog grooming.


Tip #2: Treat the backlog grooming meeting just like the first part of the Sprint Planning Meeting

  • Often called “The”What” of the sprint planning meeting, this part of the meeting talks about what will be developed in the upcoming sprint.
    • The PO presents the backlog items (often User Stories), the team ask for clarifications, and then the items are estimated by the team.
      • The PO then might indicate that priorities will change based on the estimate. Good! That’s the kind of collaboration that’s supposed to occur!

Tip #3: Make sure the PO knows that, during all of this sprint’s backlog grooming sessions, they will be expected to present enough work to last about 1.25 sprints or so.

The reason for bringing this much work to the meeting is twofold:
1. Often times PBI’s will be de-prioritized based on feedback in the meeting, so you want enough work leftover that you’ll be ready to fill a sprint.
2. It’s a good practice anyway to have a couple of finely groomed PBI’s beyond what you’re working on in a Sprint in case someone frees up and needs more work.

The PO may need to collaborate with the team to know how much work 1.25 Sprints worth is, but it need not be a lengthy discussion — just a very rough guess. Hopefully your team has seen the PBI’s at a Release Planning meeting or in some other backlog grooming discussion meeting. If not, then the PO can discuss the new PBI with a team member or two(informal product backlog grooming) to get a feel for the very rough effort involved.


Tip #4: The backlog items should be fine grained and well understood by the PO for this meeting to work well. Try to have an initial set of acceptance tests defined before the meeting occurs.

When the PO brings a backlog item to the meeting, what you don’t want to hear is, “Ok, I don’t have a lot of details on this item, but I’ve got the basic gist(or first draft) of it.” What you would rather hear is this “I’ve worked on this item and I have informally collaborated with both the customers and the team on it. I have a really good idea of the details of the backlog item as well as the acceptance tests for the PBI. It’s fairly solid, and I think there’s enough information there to start work almost immediately!”

Even if the initial acceptance tests are high level, that is better than no acceptance tests at all. The more the PO and team focus on getting to good detailed acceptance tests, the better.


Tip#5: Make sure everyone understands that estimates are not final until a PBI has been accepted into a sprint.

Since the team is getting a preview of the PBI’s, don’t let the team stress out too much on the estimates. Let them know that a PBI’s estimate is not final until the PBI has been accepted into the sprint. If someone comes up with new information between the Sprint Preview and the Sprint Planning Meeting, they are free to bring it up and re-estimate the PBI. This brings us to the converse of this tip.


Tip #6: Make sure everyone understands that priorities are not final until a PBI has been accepted into a sprint.

The PO is free to change the priorities of the backlog between the Sprint Preview and Sprint Planning Meeting. This is ok. We welcome late change, remember? In practice, though, I’ve found big priority changes happen rarely between the backlog grooming and Sprint Planning meeting, maybe 10% of the time or less.

While it may be frustrating for PBI’s to change priority often, remember that this kind of information is something we want sooner rather than later.


Tip #7: Keep your eye on the goals of the meeting

One of the goals of the meeting is that, when it’s over, the team has a handful of PBI’s queued up and ready to roll into a Sprint. All major questions have been answered (or at least assigned to someone to answer), and the team feels confident and knowledgeable about the upcoming work. Of course, like everything, not every last detail will be known, but it’s not for a lack of trying. At the end of the meeting you might try asking this of the team: “Of all of the PBI’s that were presented, a) which ones would make you feel very uncomfortable if you had to start tomorrow?and b) which ones do you not feel confident at all in estimating?” If any of these kinds of risk are identified, assign someone to help mitigate that risk before the upcoming sprint. This brings us to our next tip(available in Part 3 of this blog series — or you can click on the link to the full article below).

Link to Full Article:

Tips For Effective Backlog Grooming

What your backlog grooming tips?  Post them in the comments.

Sprint Tasking Tips: Sticky Note Strategies

Tip: Defer task assignment

Try not to ever assume who will be working on a task. Further, don’t assign tasks to people in the Sprint Planning meeting. Instead, let people sign up for tasks just in time during the sprint. This helps reduce bottlenecks and critical pathing issues.


Tip: Strongly consider notating task signup on stickies

Most teams already do this anyway, but notating the person who is currently working the task greatly increases transparency.


Tip: Strongly prefer sticky notes over software to manage tasks

  • Low tech is the best tech!
  • Managing items at the granular task level is an extreme pain in the arse in a software tool. Strongly prefer stickies on a board!
  • Note for teams where members are not within 50 feet of each other:
    • If only a couple of your members are not within 50 feet, prefer sending a picture from a camera phone over making everyone use a software tool.
    • If many of your members are not within 50 feet, then you will probably have no other choice but to use a software tool. Prefer a very simple tool. Many of the Scrum management tools out there have a ginormous amount of bloat in them including many features that are not in line with the Scrum Guide.

Tip: Innovate with your task stickies

Some teams notate stickies by:

  • Adding a sticker to the sticky
  • Writing something or some symbol on the sticky
  • Using a different colored sticky

Don’t go overboard with this, but think about innovating your sticky system as follows:

  • Consider notating task stickies
    • that represent an external dependency (I usually use zero hour tasks for this)
    • that are on the “critical path”
    • that require “paired programming” or other required practices
    • for tasks that are “blocked”
  • Consider changing the way task stickies are arranged on the board
    • to illustrate task dependency
      • but also consider removing task dependencies if that’s easily accomplished
    • to illustrate the critical path
  • Consider using a different colored sticky for tasks
    • that represent an external dependency
    • that represent defects or bugs
  • Come up with your own way to innovate your task sticky system!

Again, don’t overdo it but do tune your sticky note system to your team’s needs. Also, be sure you’re not violating some principle of the Scrum Guide by notating your stickies.

Link to full article:  Sprint Tasking Tips

What are your favorite Sticky Note Strategies?  Post them in the comments.

Sprint Tasking Tips: Team tasking strategies

Tip: Try to estimate tasks as a team.

Don’t take this the wrong way. I’m *not* suggesting that you all sit around a table and estimate tasks like Planning Poker or anything. Besides, Planning Poker is for sizing Product Backlog Items, not Sprint tasks. What I am suggesting is that when your team does Sprint tasking, generally in the Sprint Planning Meeting, allow the entire team to see the tasks and suggest modifications. Typically, with an experienced team, I recommend the team split up into pairs to create tasks for each Product Backlog Item. I then have the team re-join later and let the entire team view all tasks and their estimates. I then encourage the team to spend a short amount of time tweaking the tasks and estimates. Don’t fall into task analysis paralysis or anything, just give some short amount of time for some high priority tweaking. Whatever you do, don’t overthink task estimates! Just put something down quickly and then retrospect on it later.


Tip: Re-tasking mid-sprint is perfectly acceptable

It is perfectly acceptable to re-task one or more tasks mid sprint. Sometimes, you’re just not able to accurately predict the tasks for your sprint. The most important thing about your Scrum board is that it accurately reflects the work remaining in the sprint, to the best of everyone’s knowledge. I recommend you do not re-task alone. The tasks were originally created as a team in the Sprint Planning Meeting, so it’s important that you don’t re-design tasks alone. Consult with at least one team member when you’re doing this. Also, inform whoever updates your Sprint burndown so that the calculations stay correct. If the re-tasking is noteworthy, take 30 seconds to increase transparency by letting the entire team know about the re-tasking activity at the Daily Scrum.


Tip: Make sure the Team fully understands all Tasks

Sometimes a small sub-portion of the Team will do the initial creation and estimation of tasks. In these cases, make sure that the Team eventually takes a broad view of the Sprint Backlog before finishing the Sprint Planning Meeting. Near the end of the meeting is a good time to have the entire team view the entire Sprint Backlog and get clarifications make tweaks. Don’t get too caught up in the clarifications, of course. Whatever you do, don’t overthink tasks! Just create simple tasks and then retrospect on them later.

Link to full article:  Sprint Tasking Tips

What are your favorite Sprint Tasking Tips?  Post them in the comments.

Follow

Get every new post delivered to your Inbox.

Join 286 other followers

%d bloggers like this: