How long is a piece of design?
This question is frequently raised when discussing the estimation of design effort. Always asked without not much hope of an answer.
Let’s look at some common reasons for estimating design:
- Project managers or product owners who are keen to monitor timelines and resources.
- Other teams who need to know when dealing with dependencies.
- Team members who want to know when they can start building out your work.
These all look related to the act of planning, monitoring and resource management. This is why we estimate right?
However the joking nature of the question symbolises a glimpse of how design is viewed. Deep down - are they under the assumption that design is a vague cloud and is beyond description. Is design an abyss that tight fisted financial controllers throw hard earned money into?
Without description can the practice of design maintain value?
An alternate perspective on estimation
If the act of estimating shows contempt for the craft - perhaps the act of estimating also offers an answer.
I heard an alternate perspective today - by estimating design effort we increase credibility of the design process and rigour around our approach. Without structure, process and clear definition it can be hard for any activity to have value within a business.
After all - many companies thrive on predictability and accountability - it ensures governance and planning are maintained. A defendable process appears more predictable and accountable.
So with this in mind, what are some of the reasons we might want to consider estimating design effort?
- Give people visibility into our process
- Create focus around tasks at hand to keep work moving
- Provide clarity to timeframes and planning
These all revolve around people understanding what we are doing and gaining onsite into the activity of design. The estimation itself gives us a framework from which to set expectations and co-ordinate efforts.
You say, I hear …
Ok Sure, BUT - if you ask me to estimate design effort I shiver. Why? When someone says “Estimate” I hear “give me a number so I can tie you to it when push comes to shove”.
So how can we use estimates to provide rigour in our process yet protect us from zealous constraints and claustrophobic planning.
Understand the need.
We need to understand the “Why” we are providing the estimate. How will the estimate be used and at what point will you have an opportunity to reset expectations around the estimate.
Martin Fowler comments on this in his recent Blog:
“For me, estimation is valuable when it helps you make a significant decision.” - Martin Fowler
This could manifest in many ways but the clarity an estimate brings can help advise what we trade-off or when we may need to put a halt to a project when the effort far outweighs the value. THese can all be important decisions and a design team with a blanket refusal blanket to estimate puts them out of synch with others within their team.
Estimates have a limited shelf life
So you have created an estimate - and it helps you get so far. Don’t forget though - when the estimate is no longer useful. Perahps some of the assumptions you made to form the estimate are no longer valid. Perhaps the constraints on your work have tightened - or perhaps you nailed it the first time. These are all good reasons to reassess your estimate or to simply retract it if re-estimation offers no further value.
Remember, the estimate itself is simply a tool to help us get the job done. Not a ruler we use to measure its value.
Estimation is waste
Finally we should ensure we remember that the estimate itself is thrown away. As teams we deliver working software - not estimates, gant charts and timelines. However, estimation allows for potentially better projection, forecasts and as discussed - it injects design values back into the broader business.
It is this value that we weigh up against the effort that estimation takes. So don’t jump straight into estimates, however don’t write them off either. They may just be the tool you need to help give design the rigour and credibility it needs.
Some reading that informed my thoughts on this issue - http://martinfowler.com/bliki/PurposeOfEstimation.html - http://michaellant.com/2010/07/05/estimating-effort-for-your-agile-stories-2/