Why should consulting partners estimate requirements using time, and not story points?
Because unless they are doing a pure agile project with full buy-in from customer, their proposal/quote is for the amount of time to deliver the project (for a Time & Materials approach, instead of Fixed Price).
Estimation should take into account:
– amount of work to do
– complexity of the work
– risk and uncertainty in executing the work
The important thing about applying story points to user stories for an agile approach to software development is the relative ratios against the other user stories.
Two developers may estimate a piece of functionality quite differently, depending on their experience, skill and capability.
This makes product development a little challenging.
However, you’re likely to get a consensus when asking them to rate the amount of work relative to other functionalities and allow them to achieve efficiency and velocity within the team as they dig deeper into the software and get to understand how to work with each other better.
This does not really work when you’re quoting work as a Consulting Partner though, as our unit of measurement is our day rate.
I hear arguments about both estimation approach, and sometimes I think it’s like the duck arguing with the chicken, as the chinese say.
There is no wrong answer… in the correct context.
Don’t be a banana. Make sure you get your context right.
#zenhaoprotip
#estimatingprojects
#projectmanagement
#salesforce
#crm
#softwareconsulting
#consultinglife