Skip to content

Sprint planning estimation in “user tasks”

August 27, 2015

Goal is not to start another war between the #NoEstimates and the others – I still like the idea of Mike Cohn: Commitment-driven.

The goal is to see how I could replace splitting tasks into hours (#NoEstimates?) to get commitment and tracking progress for the benefit of the team.

Option 1: classic commitment driven

Option 2: slicing user stories into “tasks” less than 1 day (#NoEstimate?).

Option 1 – Estimation story points and hours

Step 1: Estimate in story points – using planning poker where the goal isn’t only to get estimates but to clarify user stories: this is a coaching tool, not an estimation tool.

Step 2: Break down user stories into tasks and estimate them in hours at sprint planning. Use “hours left” to calibrate “commitment” for following sprints.

 

Option 2: Estimation story points and user tasks less than a day

Step 1: same

Step 2: At sprint planning, break down your user stories in smaller “user tasks” (task a the user can complete): they aren’t “user stories” per se but instead of splitting them “waterfall” style, you break them in terms of “workflows” that could possibly add values.

Let’s say you have a 5 point user story about “customer log in”, you could have “user tasks” as opposed to “development tasks” such as:

  • Customer has a in valid email or password
  • Customer is offered to create an account
  • Customer can retrieve his password
  • Customer can retrieve his email address
  • Customer has a valid user name and password

Now we are happy, they can all be implemented within a day (if not we slice again the not small enough ones) – this is to keep the idea of achieving something every day: “small” means less than a day. So, looking closely, these seem like acceptance tests in fact (so I am going in the direction of Ron Jeffrey in that context).

So I guess I have not “estimated” tasks into hours hence I am a #NoEstimates (from what I have read). So the team can go ahead with their sprint!

For tracking, we could say in the first sprint, we have 50 days of work and commit to 60 “user tasks” and we commit based on “user tasks” all less than 1 day and see how we perform (calibration). Then I can use cycle-time.

Advantages:

  • No need to break user story down until we decide to implement them: “just-in-time”
  • We keep velocity as it works and planning poker as a coaching tool.
  • We reduce waste or kill 2 birds with one stone: we break down user stories into acceptance tests (“user tasks”).

Disadvantages:

  • Less than 1 day is still a day: let’s assume one engineer starts implementing a user task that should be a couple of hours but she/he believes there is more work involved and ends up spending the whole day: this is waste. Hold on: this is miscommunication so let’s put a process. Hold on: processes? Not very agile… What is the likelyhood of this happening? In fact, probably quite low: there is a design task to clarify further; if you waste time once, you may want to think further next time.
  • You miss the simple chat: I still think for clarity, since you have already broken down user stories into tasks, a quick estimate on hours allows double-checking we are all clear. In fact, the whole point of estimating isn’t getting getting estimates, this is to make sure we are on the same wavelength. JUST TO BE CLEAR: the purpose isn’t to have a list of tasks and hours: it is to arrive to a commitment.

What about classic tasks such as design, unit testing etc?

  • Now, some user stories may require some level of thinking in terms of design so why not be explicit about it. You can add a design task.
  • What about code review? This is in the DoD so technically, you can add it to the work with the user task.
  • What about unit testing? Acceptance tests? Same, since this is part of DoD, this is included in the user task.

So a user task is done follows the same DoD than a user story. So we have done is breaking down user stories into small valuable tasks.

So what is left to “estimate” is effort for the design and design should be less than a day quite likely.

Conclusion:

You can break down user stories into design of the user stories and acceptance tests and use cycle time.

You can also get quite estimates on each user tasks but with the goal in mind to just double-check we are all on the samewavelength and that can’t cost much.

“To make an idea work, you need to build on an idea, not destroy it”

 

Estimating in user tasks

Advertisements

From → Agile, Estimation

2 Comments
  1. Doesn’t this just explain that #NoEstimates makes more sense for this scenario?

    • Hi Joshua,

      Thanks for your feedback – I have tried to rephrase some of the post to make it clearer.

      Hope it works better.

      Thanks
      Ch

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: