Story points vs man-days for sizing new work

‍

Story point estimation takes into consideration the volume of work within the scope of the story (how much is there to do?), work complexity (how hard is it to do?) and uncertainty (what’s not known in this story?). Story points are assigned by all team members through a planning poker exercise and do not take into consideration which team members will be doing the work or the time needed to complete it. 

But why is relative estimation using story points our preferred method of sizing new work? Here are some arguments we use while advocating for this practice to be used by all delivery teams we work with.

Maximises team productivity

If an experienced team member gets a story estimated at 3 man-days and completes the work in a day, most likely they will be idling for the remaining 2 days or take this as direct feedback that they work too fast. Likewise, if they are less senior and unable to finish the work on the story within 3 days, they will be stressed and work overtime to finish the story and blame their team lead for having unrealistic timelines for their work. In either case the man-days estimate distorts the team member productivity and morale. With story points that cannot be converted into man-days or hours, we maximise the productivity of the team, assuming each member is motivated to deliver maximum value with the skills they have.

Leaves room for productivity fluctuations

Man-days estimation assumes that the productivity of each team member at any point of time is the same. However, that’s not true as each developer has their experience with the product. Their skillset and the work on the same story will take different time for different team members as a result. The more time the team works on the product, the more productive it should become. The productivity is likely to drop during festive seasons, major release time or if the team resources are overstretched. With the help of story points we can measure team velocity and see it change in real time, sprint by sprint. Therefore, we can make sure we always update our delivery forecast based on the most recent team velocity and work on team motivation, impediments removal, strong communication and delivery pace to complete more scope within a fixed time period.

Easier to agree

It’s much easier to compare a story to the baseline scale of relative sizes or already completed stories and assign a relative size to it. With the man-day estimates the discussions around how much time it will take to complete a story will take much longer, given that each team member will be comparing the work within the story to their skillset and speed of work. What takes a lead engineer a couple hours might take a junior developer days to complete. Relative sizing becomes a great whole team learning exercise and with the right approach to it can be fun and engaging.

Faster to estimate

The gist of relative sizing is just comparing new stories in the backlog to a baseline scale of relative sizes - this approach can be performed much faster than agreeing on the number of man-days required to build it. Relative sizing is just as fast for sizing features, epics and stories, backlog items of different levels of granularity. The more you estimate, the faster you get. Saving time on estimation leaves your team more time to focus on actually building the solution and delivering value.

Allows to have a realistic release date forecast

With the man-days estimate you’re setting yourself up for a failure while predicting when some functionality will be delivered. Man-days estimates assume the team performance is always the same and every team member works with the same speed. However, in real life people may leave the team, new people can join the team to replace them, this impacts the team velocity and ability to deliver the functionality scope by the previously agreed timeline. By constantly measuring team velocity and comparing it to the total estimate of the remaining work in the backlog, you can accurately forecast the release date. And if it’s not what you ideally want, there’s always room for negotiating the scope of the release, bringing more people to the team or postponing the go live date.

With all of these benefits of story points, it’s important to mention that relative sizing can be harder to explain to others, especially to people managing the time and the budget of the project. Story points also don’t work if used incorrectly, when there’s a fixed conversion rate to man-days, or not all team members take part in the sizing exercise, or there is no fixed product team working on delivering this value.