Seems I'm out of a job :)

I'm not a fan of hours based estimating myself. In the past I've tried breaking stories into tasks with hours associated to tasks. Frequently I found that not all the tasks necessary to complete a story were thought of up front, and that testing/user acceptance was never included in the time. So we frequently ended up with the "Well, it's code complete but just waiting for testing." statements.

I'm trying to move my team to a pure story driven project management where we don't worry about tasks, it's just -> Is the story done? No. OK, then finish it. If any critical tasks are necessary for a story they can be noted on the card. Stories are sized at the start of the cycle and we include QA in the sizing of the story.

Our first few tries at doing this have led to a more value focused cycle, and I think is even less project management since we don't need to estimate time left in the middle of project cycles. .

Of course, probably what it really comes down to is what is the team comfortable with and that's what will lead to real success.

I agree that <.5 day scheduling is probably meaningless and wrong (for me, something either takes literally 5 min, or is half a day.... there's never 2 hrs), but I wonder why do you prefer to group small tasks? I tend to prefer small task scheduling, between .5 day and 2 days and always try to break anything >= 5 days

You've been kicked (a good thing) - Trackback from DotNetKicks.com

Thank you for submitting this cool story - Trackback from DotNetShoutout

Why do you prefer estimating in ideal hours instead of estimating in story points? I find story point estimating better because the estimate will be the same whoever does the work. Different developers might need more or less time in order to solve the same task.

After some iterations of story point estimating, the team is used to the technique and the scale (which can and will differ from team to team).

Every new client I work for I've brought up similar points. I break my day into two blocks of 4 hours and estimate in 4 hour blocks. if something's expected to take less than 4 hours then I group it up with something else or pencil it in for the afternoon when I'm typically side-tracked with other stuff, meetings, etc.

I have worked in extremes where clients expected every task to be tracked with an estimate and actual recorded against it. Maybe it improves their forecasting but it certainly adds weight/cost to the project.

Project managers do have some uses though. They're typically quite good at shielding development teams from the pressure/wrath of management. I've worked with some really good ones, but most are ineffective.

I'd recommend Planning Poker as a technique for achieving that style of estimation: www.planningpoker.com/detail.html

Pingback from  Dew Drop - March 12, 2009 | Alvin Ashcraft's Morning Dew

How many hours were estimated to get RedMine up and running?  It's ridiculous.

But what you are talking about is not some kind of project manager?  I think I didn't completely understand your article.

I also vote for never using ideal days.

First off, they're not a very accurate way to estimate. Estimating time is something almost everyone almost always gets wrong. You can have no confidence in your estimates that way.

Developers are better at comparing complexity of tasks than estimating time a given task will take.

Secondly, too many management types just see the number of days, and therefore turn an estimate into a delivery date (and too many of them refuse to be educated differently). That way a world of pain lies.

Also, doing velocity calculations gets a bit weird if you estimate in ideal days. You get ideal days/week (or similar), which is a tad confusing for some. Correcting estimates also gets confusing with multiple meanings of "day".

We have a similar setup, but still have a project manager who watches over two teams. He doesn't interfere much though apart from when we can't agree on something or have a problem we can't decide on ourselves.

He mainly watches over and maintains Mingle, our web app for managing ideas, storys, bugs, iterations, releases etc...

One thing we definitely don't do is time based estimation. The reason for this, is as a developer matures, tasks take you less time. This makes it difficult to measure a teams performance as the goal posts keep moving. Therefore we use point based estimation, but keep a wall of previously estimated stories to compare against when estimating a new story.

We also use planning poker for estimating a story. We go over the story then when everyone is ready we all draw a card as to how many points we think it's worth. This stops people being persuaded by others as they can't see their estimates.

We include dev and qa as part of the estimate. I often find companies estimate just using dev's, but testing is part of the commitment and should not be left out. Once a story has been estimated, we note who was present which is handy. I've often had to work on a story I've not estimated, so it's good to know who did estimate it so I can talk to them should I need to.

Like you mentioned we keep large tasks broken down. Typically anything that will take more than 5 days gets broken down further. The smallest story should take us no longer than half a day though, as we don't want to get too granular.

One of the things that's confused me with time based tracking is that developers take a lot of breaks, and can't be working on each task constantly.  Should the estimation include these breaks into each task?  Should it be proportionate to how long the task will take?

There might not be an answer for this, but like I said, it's why I've never really like time estimation

Pingback from  Software Quality Digest - 2009-03-13 | No bug left behind

Bobby, you generally want a developer to estimate how long it would take complete a task as if they could work un-interupted.  This way you can figure out what sort of modifier you need to multiply their hours/days by to come up with a "real" estimate.

For example, let's say I'm constantly in meetings and getting pulled off projects to go golfing with the executives, in reality it means my 8hr task takes 40 to complete, so in the future, any task that I estimate you can simply multiply it by 5 to get the "real" estimate.

Of course, this assumes that every week is the same by ways of interuptions and a bunch of other variables that can easily muck up the calculations, but assuming you have enough history with a given developer, it's better than nothing.

Pingback from  ??????????  &raquo; Blog Archive   &raquo; ???????????????? ?? agile, ?????? ?????? ?? ???????? ????????????????

@Bobby, that's the danger with time based estimates. You should however, definitely not include breaks etc... The estimate should be in "ideal" hours, ie if you could work uninterrupted.

If you want to track it in more detail, make sure you do detailed task breakdowns for each story and get developers to put that actual hours against each task. That way you can total up how long a story actually took to complete, and compare it with the ideal hours estimate. The tricky part is getting developers to fill it out in the first place, and to be honest!

@AndrewLV, I find "real" estimates dangerous.  As you mention each week may differ, and also for each task it may differ. I'd personally avoid such a calculation as you're attaching other work activities to how long a task can take.

I think they should be separate. Going to meetings and having breaks is a part of the job and should be expected.

The development team should make an agreed commitment prior to planning an iteration, as to how much they can complete. This has to take account of meetings, people being on holiday, breaks etc...

That's why I prefer point based estimates. It's much easier to apply than trying to think of how many hours it will take (which developers more than often get wrong).

Using the fibonacci is a good way of estimating. 1, 2, 3, 5, 8, 13 etc... It forces developers to pick their estimates better. Also for larger estimates you shouldn't be concerned with detail. The larger the story, the less accurate you can be, which is why it's good to break down large stories.

In a company that makes business decisions based on some level of return on investment, it would be responsible to be able to reliably make estimates and determine some velocity based on those estimates. Story points based on a relative story (i.e. user login) estimated on the fibonacci (planning poker) is probably a best practice. It addresses the issues of performance improvement (as you improve performance, you have a new story point velocity).

In organizations where something is sold other than just code (i.e. support, implementation, related services) or the organization needs to change its support (marketing, sales, finance), you are going to want a project manager. This is just about every company. The project managers job should not be to micro-manage the developers. They  can be self organized and managing once they learn how to make and keep reliable promises about quality and velocity. The project manager should be making sure team is getting everything it needs to be productive during iterations, the rest of the organization is aligned with releases, the financial reporting is complete, etc.

I think comments like the one that started this post lead to conflict that delays an organization's ability to deliver value to the customer. It would be far more productive to help everyone get in the appropriate role to improve the flow of value.

Rob,

While I am in no way advocating the way I suggested ("real" time estimates), but the reality is, that is often how estimates are made.  If something needs to get done by a deadline but the developer who is working on it is constantly pulled off the work, that is a something that needs to be known by someone, or a deadline is going to be missed even though said developer technically had plenty of hours to complete the job.

Again, I'm not saying it's right or wrong, just that someone (or something) needs to take account other work activities into timelines.