Re: [scrumdevelopment] Complexity X Time
- Hello, Heitor. On Wednesday, June 30, 2010, at 11:18:36 PM, you
> don't need to estimate complexity or don't need to estimate *anything* atIf you want to estimate, estimate time. If you don't want to
estimate, there is no real need to do so.
It is a bad plan that admits of no modifications. -- Publius Syrus (ca. 42 BCE)
- Adam & Mark,
I find the estimating of stories and tasks done with a light touch is no a waste, but rather a communication of expectations.
For Stories, using Mike Cohn's guidance on numerical estimating, I find setting the expectation that it should no more accurate than the metaphor of t-shirt sizes: S, M, L, XL (XXL?) that frees people to have a quick consensus on what's being committed to when a team takes on a story.
For tasks, also using a light touch, it's a quick and easy step to communicate evolving expectations that can be changed on the fly as learning takes place. This informs transparent communication to all stakeholders of the sate of an iteration.
I find that Adam's scenario is exactly what I encourage for my clients. It starts with acknowledging what's known and not known. This also resembles my advice to CIOs in talking to their CEOs and budgeting committees: Based on this investment rate, like funding an R&D organization, I can do this much (X) for sure. If we're really lucky in discovering and developing new functionality, I can envision this dream level (Y) being achieved. And we are most likely to reach some intermediate level of functionality (Z). If X is sufficient for funding our loaded flow rate, let's get started.
Anyone with experience knows that any other statement of certainty is self-deception or worse. However, many people are so steeped in a false claims of predictability as a standard of professionalism that it's difficult to change those organizations.
In my Agile consulting, my prime objective is to create a safe environment for all to say, "I don't know." Then we can focus on delivery good stuff fast. As a matter of integrity, I hope all of us Agile, Scrum, XP, Kanban, Lean, etc. consultants do the same.
--- In email@example.com, Adam Sroka <adam.sroka@...> wrote:
> On Wed, Jun 30, 2010 at 8:02 PM, Mark Levison <mark@...> wrote:
> > I've not met Adam so can claim to be neither a mentor or peer. However my experience chimes with his. Estimation is a waste. Estimation of tasks in hours is utter waste, people spend hours debating minutia, when they would better off just starting. Even estimation of stories in points is a waste, however to make your projects progress predictable and transparent this requires that stories be roughly the same size +/- one Delta. For most teams (mature or not) this turns out to be difficult, so they stick to story points.
> True, but I can imagine a highly functioning organization able to have
> the following conversation:
> Boss: "We have this really big thing we'd like you to do. What do you
> think it'll take?"
> Team: "We've done some other big things that aren't entirely different
> from that thing, and they took an average of about six months. So,
> we're thinking it'll take between four and eight months to get it all
> into production."
> Boss: "Great! I know that it costs about $50K to keep you guys running
> for a month. That means that this is going to cost me about $200-400K.
> Based on what we know of the market that should be well worth it. When
> will you have something to show us?"
> Team: "In about a week, but before we start let's sit down and write
> some user stories so that we can prioritize them and get a better feel
> for what the first pieces of functionality will be."