Agile Ramblings

Home » 2013 » May

Monthly Archives: May 2013

Who is Estimating?

Part 3 of my Exploration of Estimation

In part 1, I posed the question of Why are you estimating! I hope that you thought about it and may have found an answer or two.

Part 2 explored What are we estimating. Usually we are asked to estimate effort (cost) which is then turned into a schedule (duration) which are two very different things.

The next question I’d to explore is Who is doing the estimating?

In my experience,  normally it is the technical people who will be doing the actually work (coding, sql, ux, etc) that are asked to provide an estimate. Developers are the best and most familiar example. And while at first glance this seems reasonable, when you start to dig into the entire workflow required to move an idea to reality in software, it begins to look a bit inadequate.

 

image

 

As we can see in the workflow, there are several phases of life that a feature/user story/use case goes from to be brought to life, only one of which is development. Often, there are many tasks across elaboration/analysis, development,  quality assurance, user acceptance and IT/Ops just to name a few common phases. Are developers performing all of these tasks? Do they take into account the effort required in all of the other disciplines when they do their estimates?

So why is it that developers are usually the only ones estimating effort?

 

image

Surely developers aren’t the only one working on your projects!! (Don’t get me wrong. I was a developer growing up, so I’ve definitely thought that the software development workflow revolved around me!) But this is a team sport, and without the business analysts, QA professionals, IT professionals and what ever other role is in your delivery workflow, we may have a difficult if not impossible time getting our software out the door!

 

image

 

So as a part of your estimation process, how do you understand the effort and/or time required to get work through the entire delivery process?  Do you take into account all of the phases of life, and hand-offs, and interactions in your delivery process? Do you get all of the people involved in the estimation process? In fact, I’ve seen (not often) teams involve a tester in the estimation efforts, but very infrequently do I see analysts, DBAs or IT/Ops folks involved in the process, even when they’re role is critical to the delivery of the product!

So who is involved in YOUR estimation process? Do you have all the people you should have involved?

And are you asking yourself this question in conjunction with the other two questions I’ve already asked you about? Hmmm….. I hope you’re all thinking about all of these questions! I hope to present a couple more questions in the next week and then start to tell you how I think we can start make some real changes in the way that we do all of this estimation stuff!!

What Are You Estimating

Part 2 of my Exploration of Estimation

In part 1, I posed the question of Why are you estimating! I hope that you thought about it and may have found an answer or two.

The next question I’d love for you to think about is What are you estimating?

I was just in a meeting that was discussing a RFP for a client. This is pretty common in the consulting industry where we see a Request For Proposal and in that, we need to define the scope of work that we can address, align our skills and services to deliver  that scope of work and then provide an estimated cost for that service. Seems kind of normal. But then we are also sometimes required to provide an estimated calendar duration for the project. So in essence, we are being asked to provide 2 estimates. We then present our guess (educated) at how much work needs to be done, and here is our guess (educated) about how long it will take the team to execute on that vision.

So when the developers were being asked to provide estimates to the work in the RFP, what do you think were they estimating?

I haven’t had a chance to ask them yet, but based on my experience (as both a developer and a person being asked to provide project duration estimate), the development team is probably estimating effort and not duration.

So who estimates duration then? How do we get duration from effort? And if we stacking a guess (how fast we deliver) on top of a guess (effort), are we getting a meaningful expected duration value?

If you go back to my rant on estimation (which I will reference often in this exploration series) you will see how most organizations, in my experience, do mental and mathematic gymnastics to come up with an expected duration value.

My belief is that we are not getting a useful duration value. But everyone treats it as useful, starts building elaborate project plans and organizational activities around this duration value, and then we are all shocked when we have to change request the project, drop scope, or scramble like crazy (and usually with questionable quality) in the latter half of the project when it becomes painfully obvious that we’re not going to make our original duration estimate. Either way, the initial setting of expectations based on the layer of several guesses seems to be a Bad Thing™.

So I’ll leave you with this final question, what are you estimating?

p.s. I will explore better ways soon! Just bear with me for a bit longer! Open-mouthed smile

Why Are You Estimating

Part 1 of my Estimation Series

A while I go, I wrote up a bit of a rant on a crazy estimation scenario that was presented to me by a colleague. If you didn’t get a chance to read it, you can find it here. We’ll call that rant Part .5 of this series of blog posts on estimation.

Since then, I’ve seen a bit of a swell on twitter of the #noestimates hashtag and a lot of discussion on topic. I was recently saw a tweet from Allan Shalloway that prompted a bit of a conversation:

image

(click imagine to see original tweet and conversation)

As you might have guessed, my thinking is more aligned with the #noestimates crowd and I’ll elaborate that over the coming months here, but this tweet started a conversation that I’ve had before.

Why do you estimate?

If I’m going to encourage you to stop estimating, it’s really important that we understand what I’m encouraging you to stop vs. what you might actually be doing.

As the conversation continued, Allan stated:

image

…which made wonder if we’re confusing prioritization with sizing, which is actually quite common.

So I won’t re-post the entire twitter conversation here, but I’ll start to share my thoughts on the why of estimate.

Intent

When I engage in an “estimating” exercise with a team, I very often try and restate the activity as a sizing exercise. For me, this starts us down the road of using the language that more accurately describes the end goal of our exercise. We want, to the best of our ability, describe how “big” we think this work item is. I’d like the team to use their past experience and compare the current work item (requirement, user story, etc.) against similar work items they’ve worked on before. This is a relative sizing technique that is used all the time by other agile methodologies such as Scrum or XP. You’ll often here the term “yesterday’s weather” in the same conversation about agile estimation techniques. The best predictor of today’s weather is yesterday’s. The team’s recent experience is the best predictor of its near-term current capabilities.

To me, the really important point of this exercise is sizing! Not scheduling. Not prioritizing. Those are completely different activities! The product owner/business representative on the  team will tell you, perhaps with size as a decision input, what is next and when they might hope for it to be done. I generally expect them to help the team constrain the story, but the delivery team are the ones that are responsible for determine the size of the story.

So in my mind, the intent of the “estimation” exercise is to allow the whole delivery team to determine the relative size of the story compared to work items they have done in the past.

Why?

So why are we asking delivery teams (Development, Ops, anyone who is creating value) to size their work items? This is where I think all of the estimation craziness and problems start.

We need to provide some sort of indication of the anticipated financial impact to the organization making the request of this work item. We also need to provide information that would allow us to set a delivery timeframe expectation. And the next level of this problem is to take 100s (or 1000s) of these work items and provide the same financial and delivery timeframe expectations. This is, for most teams, really really hard.

And I will state that it is my belief that size is not the primary factor in determining cost or delivery timeframe. Will a bigger story cost more? Usually, yes, but not always. Will a bigger story take longer? Usually, yes, but not always. What if to delivery a story, a team has no external dependencies? What if it does? What if the story is big, but a really well known problem? Unknown problem? What if the team is missing a team member when it finally pulls the story from the backlog? What if the team composition has improved?  There are so many things that can change the cost and expected delivery timeframe in addition to the size of the story that are very difficult to predict.

So in my mind, we are trying to size our work so that we can help business decision makers make the best decision for the organizations economic well being.

Final Thoughts

I’ll leave you with a couple homework questions. What is the intent of your team’s estimation exercises? Why is your team performing those exercises?

Part 2 will explore my approach to providing business decision makers with better information so that a team (business and delivery groups) can make better decisions on behalf of our organizations.