Many agile teams are left spinning their wheels when faced with the question ”How should we estimate: story points or ideal days?” We decided to take this debate to our Agile Mentors Community members to see what they had to say about it.
A lot of our members estimate differently depending on where they are in the work―if it’s a first pass at sizing the product backlog, story points or T-shirt sizing tend to be favorable. For Sprint Planning, there was a lot of conversation around breaking work into pieces that are as small as possible.
Our community estimates in many different ways, which led to some pretty healthy discussion on the topic.
1. Instead of Story Points, Try T-Shirt Sizing
One member said story points can be problematic because once a number is associated with a team, it is natural for leadership to use those numbers to compare teams. She says her teams have an agreement that anything that’s large or extra large will be broken down further during backlog refinement.
She added that it’s harder to compare teams when using T-shirt sizes because the discussion becomes, “Team A completed two smalls, one medium and started on an extra small”, and “Team B completed three smalls, one extra small and started one medium.” She explained how this language makes it clear to leadership that they are comparing apples to oranges when they try to compare the velocities of different teams.
2. Estimate the Product Backlog with Story Points
Another member thinks about estimating in stages and prefers relative size estimation with story points at the first stage, followed by time estimation for subtasks.
He says that when the teams are first looking at a feature and breaking it down, they compare the new stories to reference stories from the backlog that were previously Fibonacci sized. This gives them a rough idea of whether the feature will fit in a sprint, or whether individual stories are too big and require slicing (20 is too big for his team).
By playing Planning Poker with story points, the discussion shifts away from estimation towards a shared understanding of the requirement, he says.
One member added, “I don’t like using ideal days, or hours, or any other time units to estimate user stories. It sounds too much like a firm commitment and may hamper the team’s ability to work with fluidity.”
3. Focus on Small Stories
An experienced agile coach says he focuses his teams on getting work small enough that it can be accomplished in three-to-four days and then calling every story two points. This shifts the emphasis away from estimating and onto work that can be completed very quickly. His favorite phrase is, “Iteration happens in your head, not on your calendar.”
One member takes this a step further and breaks down work into one-day items and measures velocity by counting the number of done items each sprint. His motto is to “maximize the amount of work not done.”
Another member has a similar approach: Keep breaking stories smaller and smaller until they are all size “one” and then you just have to count them.
Yet another member noted that the question “Story points or ideal days?” leaves out the most agile approach of all: eliminate steps that do not provide value. His advice is to keep a sharp eye on whether estimating is providing the value that it costs (in terms of the time it takes to estimate).
All of this discussion led one member to wonder if one-point stories might be the fastest approach.
4. Use Time for Subtasks
Some members were in favor of estimating in time (ideal days or hours) when it comes to subtasks.
One member stated that if teams are inclined to break user stories down into subtasks he’s okay with using those hours as a sprint commitment sanity check.
He gave an example: If we are committing to 600 hours of tasks when the team only has 420 hours of bandwidth, then we should be concerned that we are overcommitted.
5. Estimating Techniques Should Evolve as Teams Mature
Once teams are really good at having small stories that cycle through rapidly, estimating sub tasks can be dropped, says a member.
She adds that when working with a new team that is used to very large stories and is recovering from waterfall, she prefers sub tasks and looking at remaining time on a daily basis. She says this gives a good, real-time picture for teams that are still learning.
Another member says that estimating differs based upon where the team is on their journey. He states that he’s more prescriptive with new teams than with teams who have mastered the basics.
He goes on to say that over time, he backs off focusing on tasks and asks the teams to self-organize in regards to how they want to manage their work at the task level.
Another member agrees that once teams mature and have a more intuitive feel for what they can accomplish at the user story level, they can drop this administrative overhead altogether.
To read the full conversation on estimating (and many more topics) consider joining the Agile Mentors Community at https://www.agilementors.com.