Managing Product Development

I taught my estimation workshop twice last week and once the week before, and one thing remains true: Estimation depends on the project lifecycle, how the project is organized, the state of the requirements, and the number of people you have available.

I used a number of simulations to help people see how to estimate, and I noticed a number of interesting effects:

• In the public workshops, people were more willing to experiment and live with a different lifecycle for a simulation (a more concurrent lifecycle, or an iterative or incremental approach)
• In the on-site workshops, the participants recreated their environment, even when they said they wanted to try something new. Goes to show you how difficult it is to change.
• Relative sizing is a great way to account for the difference in capabilities when you don’t have specialists or people with subject matter expertise. (“A 2 for this group is more time than a 2 if we had a so-and-so.”)

I encouraged people to try incremental and agile approaches to their projects in the workshop. The participants agreed that the approaches provided faster results, and still were concerned that they would not be able to implement those approaches at work. Some of the people were so accustomed to not having enough people, that even when I asked, “How many people for how long?” they could only assume they had access to the other one or two people in their small groups, even though we had 20 people in the room.

Yes, we encountered Parkinson’s Law (work expands to fill the time allotted), which is why I timeboxed the estimation time. “But we need more time for estimation!” “Do you get that time from your managers?” “No.” “So, maybe you can try some other approaches to make your estimates better in a shorter period of time?”

We discovered that non-functional requirements are more difficult to estimate than user stories or even use cases. And, it still amazed me that people are given broad brush requirements, and are then supposed to generate an accurate estimate (within 10%) with such little data. Yes, we talked about ways to iterate on your estimate to refine it. Will their managers listen? I don’t know.

We even had an opportunity to test out my claim: Multitasking nullifies all estimates. It never fails, when I teach an on-site workshop, some people think their work is more important than the workshop. Maybe it is. But I do know that when they leave and arrive and leave and arrive, it mimics what they do at work, and slows down their project. Because I break everyone into parallel groups, when they return, they can see the effect of their in-and-out behavior on their project.

When you estimate, make sure you think about how the project is organized, how many people you need when, and what information the requirements provide. Then show a confidence graph or a three-point estimate to explain how the estimate is really a guess, but a good guess, not a swag.

Tweet This Post

I’ve been teaching a project management workshop, and one of the participants said something brilliant: “If you estimate in days, you’ll be off by days. If you estimate in weeks, you’ll be off by weeks.” If you estimate in months, you will be off by months.

Here’s why. The more you can break a big task apart, the more likely you are to remember all the pieces and estimate each piece well. The less you know about a task, the more gotchas you’ll encounter, and the longer the task will take. And, the bigger the task, the more likely you are to fall into student syndrome.

If you’re a PM and you don’t understand why your schedule is slipping, look at the general task duration. Got a lot of week-long tasks? Or multiple-week-long tasks? Those tasks are slipping, and you won’t know why or by how much until the time is almost done. I bet your project will slip for a duration of several of those multi-week tasks. Replan now, breaking all those tasks into inch-pebbles. Then you’ll have a much better idea of what it will really take to finish this project. And maybe, just maybe, you won’t have that much of a delay, because delays of weeks are very different than delays of days.

Tweet This Post

I plan on about 6 hours of work in a regular day. That’s project work, not answering the phone, email, making arrangements for workshops or consulting or speaking, or invoicing, or any of the other things I do. Nope, that’s just project work.

The other half of that question is how many regular days do I have in a week? Either 3 or 4. I’ve had weeks with fewer “regular” days, where I could only accomplish 2 or 3 hours of work. This week, I’ve had 2 regular days (6 hours of work days) and 2 irregular days, where I accomplished maybe 3 hours of project work.

Since I make my own commitments, this usually works out. But not always. When it doesn’t work–when I don’t have enough project time in a week, I’ll work on the weekend. I hate to do that because I don’t have enough brain cells to work effectively the next week, making fewer regular days the following week.

If you know how much project time you have day-by-day, you have a much better chance of estimating your work on a project. So when you think about estimating your time for a given task, think about what you can accomplish in a regular day. And think about how many regular days you have in a week. If you only have one day a week where you can accomplish 6 hours of work, and the rest you can accomplish 4 hours, plan for the 4 hour every day. You won’t have less to do over time–you’ll have more.

Labels: estimation

Tweet This Post

Pawel caught me being ambiguous. See his comment, “1. I’ve seen features/fixes which required 2 days to be developed and released.”

Sorry, me too. But what I tried to say was this: A feature was estimated to be some duration of person-hours. Those person-hours have come and gone. The feature still requires another 10-12 person-hours, according to the developer. In that case, I don’t trust the estimate of 10-12 person-hours left. In my experience, the reasons for the delay generally have not been addressed. If interruptions caused the delay, more interruptions could still happen. If the delay was caused by having to change the architecture, that could happen again (and I suspect it’s likely). In my experience, until the feature is done, it’s quite difficult to predict when it will be done, which is why I like to start a new iteration to make sure it gets done.

I tried to imagine what would convince me that an updated estimate was more accurate. In the past I’ve only had one thing that would convince me: I would have to see visible progress of more work complete (more pieces of the feature complete) to agree that the estimate of what’s remaining to finish is correct. I’m trying to think of more things, and can’t right now.

Labels: estimation, iteration, timebox

Tweet This Post