Scrum Project Planning – Does a Time Estimate Equal a Promise?

project-planningscrum

If an estimate is not a promise then as a product owner how can I deliver my projects without knowing how long it will take?

Does a Scrum team work more efficiently if we treat time estimates as a promise?

How much research (preparation, effort to understand the problem) in a story is enough to come up the right estimate?

What about unexpected technical problems (problems that can really mess your initial estimates) that come up after you estimate your work?

Best Answer

Estimations are not promises etched in stone. They are the best guess the team can make about the effort required to complete the task / story.

In answer to your question "as a Product owner how can I deliver my projects with out time as a reference?", the answer is that you can and should have time as a reference (i.e. you will release on a certain date). What you do not have is the exact scope that will be in the delivery.

Note that what I said is true of each and every methodology you use for driving your development. The difference between Scrum and other methodologies (such as Waterfall), is that in Scrum this fact is acknowledged, and accounted for. What you will do, as a PO, is to prioritize your scope, and make sure that the team, at any given moment is:

Working on the most important (read: valuable) undelivered feature (task, requirement, user story)
Has successfully completed every feature that is more important than the one they are currently working on (this refers to the Definition of Done: Every completed story is tested, accepted, bug free, and feature-complete).

Having that, you can now ship, or deliver, at the drop of a hat, knowing that at any given moment, the latest build is the best product that could be shipped. This means that at the date of your original release commitment, you will deliver the best product possible.

Of course, this doesn't promise that it will consist of every story you requested of the team to develop, but you know that the remaining incomplete ones are of course the least important ones, that could easily be delivered at a later date.

Also, the estimates made by the team will be increasingly better, allowing you to have an early solid idea of what the scope will be at the end of the release. You will be able to ship a good solid product on time, with a few additional less-important features a few weeks later (you will of course be able to estimate when that will be).

As for the amount of research required - there's a law of diminishing returns in play here. If you break your stories small enough, then a little research should give you a close enough estimation. If you got them wrong, then you will amend in the next sprint and the estimates will be better. In 3-4 sprints, on average, you should have a good idea of how much scope can be delivered by the deadline (or how long it will take to complete the scope).

Related Solutions

How does a Scrum team account for infrastructure tasks in the planning meeting

They're not actually user stories. They're stakeholder stories. Unless the software is actually paid for direct by users, it's rare that a story is created entirely for their benefit.

I give you a couple of examples:

keyworded articles, which allow advertisers to have more effective adverts
CAPTCHAs, which are there to stop moderators having to deal with spam manually.

Most technical stories actually provide a business benefit, but it's rarely for the users. Phrasing them in a different way can help. I normally use Chris Matts' Feature Injection template:

In order to <achieve my goal>
As <the stakeholder who wants the goal>
I want (<some users to do>) <some stuff>.

This explicitly recognises all kinds of stakeholders, including the development team. Now you can phrase your technical stories too, calling out the business benefit:

In order to minimize the risk of deploying something broken
As the team deploying the code
We want to spend a few days on an automated deployment system.

I've written a couple of blog posts on this: They're not User Stories, and Feature Injection and handling technical stories. Hope they help.

Scrum Project – Who Handles UX?

The interaction designer

UX != UI You need a experienced interaction designer to deliver good user experience, contrary to popular belief that is not a programmer. For all of you programmers who think they can do UX (that includes me) let me say this. Getting good at interaction design requires at least as much time as getting good at programming. How much time have you spent doing pure interaction design?

In the initial phase it's the interaction designers responsibility to:

Extracting the actual goals of the solution from the product owner
Define the personas that will be using the solution.
Write scenarios that are stories on how the solution will be used.
Compile a design document that leaves little room for ambiguity from an UX standpoint

During the project it's the interaction designers task to make sure that those guidelines are followed and address any additional issues that will arise (and they will).

Many programmers will take afront to this approach I'm sure since everyone feel that they're the exception that can design "wonderful" interfaces, you're probably not. On the other hand a good interaction designer - programmer relation is often very nice for the programmer as well as they don't have to fight against a "stupid specification". Unfortunately good interaction designers are hard to find in my experience but they are out there.

As always I deeply recommend Alan Coopers books on the subject ("About Face" and "The Inmates are running the asylum")

Best Answer

Related Solutions

How does a Scrum team account for infrastructure tasks in the planning meeting

Scrum Project – Who Handles UX?

Related Topic