Return to Answer

added 2124 characters in body

Source Link

edited Feb 8, 2016 at 13:58

But wait: I haven't quite answered the question yet...!

The actual question you have is about a standard way to communicate estimations. You even include a format you'd currently go for.

First up, a lot of my text above can be summarized as these directs points of interest in your current setup:

A high level / one-page project description is still great, though perhaps not for estimations and feature lists;

Don't talk about "Redesign", instead focus on a "New Product X" (that coincidentally does a lot the original product does as well);

Setting a Scope seems like a very smart thing to do (though you may want to call it "initial scope", as the business people can and should change their mind along the way, be it at a cost);

"Description of tasks" I'd replace with a high level overview of features, but whatever you do leave out the hours estimations.

Don't include a total estimation here, unless you directly refer to the other docs (see below);

The "Risks" section is great. You can add the suggestion of doing that work asap, so you can asap change directions or cancel the project if needed.

Don't go on the defensive like you do in the last part, but instead (a) be clear in your docs that you estimate and not promise, and communicate outside informally what you feel is the difference between the two.

Now, to finally answer the question, the standard way to communicate estimations I'd recommend:

Utilize Story Points (or similar construct) and Velocity to convey estimates;

Create a Product Backlog for a high level prioritization of features;

Create a Sprint Backlog for each iteration with the next few product backlog items to work on;

Create a Burndown Chart to show progress and estimated time left;

Most Agile methods (and Scrum in particular) have the above artifacts in one way or another, and I highly recommend using those for your purpose.

Again, I recommend reading Agile Estimating and Planning because it basically is a long answer to your question. It introduces all of the above artifacts quite clearly. Searching online for those tools will also help.

Good luck!

Again, I recommend reading Agile Estimating and Planning because it basically is a long answer to your question.

But wait: I haven't quite answered the question yet...!

The actual question you have is about a standard way to communicate estimations. You even include a format you'd currently go for.

First up, a lot of my text above can be summarized as these directs points of interest in your current setup:

A high level / one-page project description is still great, though perhaps not for estimations and feature lists;

Don't talk about "Redesign", instead focus on a "New Product X" (that coincidentally does a lot the original product does as well);

Setting a Scope seems like a very smart thing to do (though you may want to call it "initial scope", as the business people can and should change their mind along the way, be it at a cost);

"Description of tasks" I'd replace with a high level overview of features, but whatever you do leave out the hours estimations.

Don't include a total estimation here, unless you directly refer to the other docs (see below);

The "Risks" section is great. You can add the suggestion of doing that work asap, so you can asap change directions or cancel the project if needed.

Don't go on the defensive like you do in the last part, but instead (a) be clear in your docs that you estimate and not promise, and communicate outside informally what you feel is the difference between the two.

Now, to finally answer the question, the standard way to communicate estimations I'd recommend:

Utilize Story Points (or similar construct) and Velocity to convey estimates;

Create a Product Backlog for a high level prioritization of features;

Create a Sprint Backlog for each iteration with the next few product backlog items to work on;

Create a Burndown Chart to show progress and estimated time left;

Most Agile methods (and Scrum in particular) have the above artifacts in one way or another, and I highly recommend using those for your purpose.

Good luck!

Source Link

created Feb 7, 2016 at 12:39

Jeroen

Oh boy, there are a few red flags in your story (some of them you've already identified yourself). These are the big ones I see:

Management asked "when will you finish"

That's somewhat great: they ask you. That's half the battle. However, if they're asking with that wording, they are asking for a promise, which is very different from an estimate. Managers tend to do that, leading to some kind of "negotiation" with their own employees. Whenever you communicate with them, be clear and distinguish between estimates and promises.

I've seen [peers] sleeping under the desk [...] this is something I am obviously not going to accept

To me, that's a sign of Death Marches (recommended reading), and not sustainable. It's good that you realize this. Be strong on this one, for your own sake/health as well as the project. On a side note, ask yourself whether you want to be in this kind of environment at all...

Redesign of X app.

Uh oh! In my personal experience, nothing is as hard as re-doing an existing feature. Joel Spolsky wrote a quite worthwhile article on the subject a few years ago, basically saying you should never rewrite a product from scratch. A nuance not easily found in the article is that you can start off a project to create something to compete with the existing product.

The reason I mention this is becaues developers and their users/managers tend to ask when the rewrite-project is done, but include the impossible requirement "And it has to do at least everything I could do with the old version.". This'll make it impossible to give estimates, if not even impossible to finish the project.

Instead, write about your project as a new product that'll compete with the old one. Any feature for the new product has to be explicitly mentioned. Only that way can you estimate with some confidence.

Is there an standard way to communicate estimations?

Yes. There are many. Most currently popular ways come from Agile methodologies. I highly recommend reading Agile Estimating and Planning. Some of the key points:

Estimates will be off. You and your manager need to accept that. They will be off by a lot early in the project, as much as a factor 0.25 - 4.00. This is known as the Cone of Uncertainty. In other words, if you estimate it'll take you 15 weeks to complete the project, it might in reality be 60.
Iterate and re-estimate. The best (perhaps even only) way to get better estimates is do some of the work and then re-estimate. Doing the parts with many unknowns as early as possible will help reduce uncertainty in estimates. Re-estimate often (e.g. after every iteration) to include new information. Communicate these re-estimations a.s.a.p.
Estimate in relative feature-size (e.g. "Story Points") first. This is easier than estimating in "man hours" or even "time left". Then do some work for a few iterations, and determine your "Velocity" (number of story points you can do in an iteration). If you have to you can combine your velocity with the number of story points left for a release to estimate when you'll be done.
Know why long-term estimations are required and include a margin of error accordingly. If the PR team needs to create a big campaign for a certain date, or if HR needs to schedule a company-wide training, there are external deadlines coupled to your estimates. Because your estimates will be off, you need to include a margin for error. However, if the estimates are neede to assess whether it's "worth it" a less precise estimate may be required.
Give bounded estimations, for example "the project will take 100 - 250 hours". Use this to introduce the cone of uncertainty to your managers, and convince them to let you work a few iterations on the product, so you can give them more precise estimates.

Again, I recommend reading Agile Estimating and Planning because it basically is a long answer to your question.