Why should we estimate? What are we considering when we do it? Yes, estimation accuracy is a matter of practice maintaining the same team constant. What and how can we estimate? We can do it all over hierarchy of requirements, since strategic levels until implementation ones. But essentially a good product planning should be done to slicing features maintaining product value and introducing complexity across the product development phases.
What are we considering when we estimate?
Estimate a user story follows an analytical process that goes through different variables:
- implementation complexity,
- time to complete it,
- dependencies from third parties to get all information together or necessary preconditions fulfilled,
- it takes in consideration who will implement it, which team, which team member, his/her experience with this type of task, technology,
- and other different factors depending on the particular use case.
Estimation accuracy is a matter of regular practice
The estimation itself can express a promise but essentially, estimations are essential to make the team confident about their commitment for a sprint, they accept in the sprint what they believe it fits their capacity. Again, capacity is measured in story points.
As often a team estimates, as more accurate it will become. Estimating regularly is a way to improve predictability and adjust expectations to the average speed or capacity. It‘s very important to have a historical base line to make decisions over time based data. Collect regularly estimations gives us this base line to trust more over time in our team estimation capacity.
Remembering a previous post: a backlog who never been estimated is a task list that we don’t know how much it costs and when will be ready.
What and how can we estimate?
Estimation can be done at all product portfolio levels: Sagas, Epics, Stories, Tasks and Sub-tasks.
The estimation practice can be done through different metrics. Story points or t-shirt sizes are the most common ones. But actually, in my opinion, we can use both in different moments in time and for different levels of requirements. For example:
If I’m estimating in the Saga or Epic level, without a deep and detailed refinement discussion, I will be using t-shirt sizes.
Going deep in details, slicing the functional requirement into implementation stories and sub-tasks, it’s more common, at that time, to estimate through story points.
If we are already running the releases in sprints, digging deep in stories, tasks and sub-tasks, discussing implementation options, essentially doing a proper refinement, is better to do so with story points.
So far, my experience is: we use t-shirt sizes in the portfolio level and story points in the product level for that we estimate stories, tasks and sub-tasks. So far the backlog is estimated in story points is better to update estimation in Epic and Saga level with story points, this during the release cycle.
But we can also estimate with metrics based on Cost and Time ranges: Man days or cost per hour. We also can use Jira to do this step.
Why are we estimating for?
Normally we estimate as a forecast, the estimation, as I mentioned before, it becomes more accurate with the regular practice without any change in the team composition.
Accuracy in the estimation is important because we need to know how much we are able to produce with the present resources, that means we will know what is our MPP (Minimum Possible Product), and we can compare it with the Minimum Viable Product to see the gap of our capacity or the required investment.
In Agile, the development team commits with the product owner to deliver some amount of stories, that means a minimum viable product will be delivered performing the minimum set of features to perform the core of the product output. But this doesn’t mean, within the first release we will have the ideal product concept. Due to this to this high uncertainty and pressure to go to market, it is extremely important to work permanently with a good UX designer, slicing the product concept in small parts, maintaining an incremental functionality in the product across the progress of the release, preserving the product consistency and functional logic for the end user.