Story points and hours

clock-70182_1280

A very common question from teams starting out with Scrum, is that about story points vs hours. How is estimation done? Can we use hours instead of points? Isn’t it the same thing? (Hint: it’s not.)

Before we proceed, I would like to make it clear that there is no definitive, general answer to how estimation should be performed, or whether you actually should be doing estimation at all. Every team must find its own answer. However, I find that the following is a good starting position.

And to get us going, we should start with the ”why?” before getting to the ”how?”.

Story points

Story points, or just points, are used in Scrum to estimate the complexity of an item in the product backlog. The estimation are typically done during refinement meetings or at the sprint planning meeting at the latest. Poker planning or swim lane sizing are common estimation methods. The purpose of the estimation is not only to get a complexity estimate – and therefore help the product owner in prioritizing – but also to check that the team has the same idea of the effort involved. The estimate is then used during sprint planning by the team to know how much work to commit to for the upcoming sprint, perhaps based on the number of points done during previous sprints.

Hours

Hours are used when estimating the tasks that needs to be done in order to reach the acceptance criteria specified in the product backlog item. If the remaining effort on each task is updated regularly during the sprint, it is possible to create a burndown chart that visualizes how much work remains to reach the sprint goal.

Comparison

Story points Hours
Estimate of… Complexity Work
Estimated at… Refinement meetings Sprint planning
Can be used to answer… How much work can we manage in a sprint? How much work remains in a sprint?
Are updated… Never; or possibly at start of next sprint if not done. Regularly.

There is no conversion factor between points and hours. Never. Ever. There is a correlation between the two, however. You would expect an item with small complexity to have tasks that sums up to a small amount of hours – but this does not always hold.

Misusing the estimates

It might be tempting to reuse the hours estimate for other purposes than the one stated above. For example, you might feel tempted to grab the number of hours from a number of tasks, multiply by some hourly rate to get a cost estimate. That is a bad idea, since that was not why the estimate was made. In fact, any idea to map the hours of the task estimates to any other measurements of hours, such as the team’s available hours, is probably a very bad idea. If you need such an estimate, ask the team explicitly for this.

Story points and hours

Do we need to do both story points and hours?

If you do not care about how many points you commit to, but instead use some other method (perhaps your gut feeling?) to know how much work to put into a sprint, then you do not need points. Beware, however, as it is quite likely that you will miss out on necessary discussions during refinement meetings.

If you do not plan to visualize the amount of remaining work, or use some other way of visualization, or if you are unable to regularly update the remaining effort, then you do not need hours.

Conclusion

Each agile team must find its own way in doing estimates (if at all), but to avoid the common pitfalls you should understand how Scrum has been implemented before. Story points and hours are used in different circumstances, and the estimation for product backlog items and tasks have different purposes. Be aware of this.

And when someone asks you to estimate the entire backlog in hours, remember to ask ”why?”.

Standing up when you make a mistake

Anyone who knows me knows that I am a firm believer in Lean and Agile principles. One of those principles is ”Respect People”, which for me extends far beyond simply treating people politely, although it includes that, it also means respecting that people are human beings and all that comes along with that.

One of the things I see in this is respecting that people make mistakes, and I try to believe that there should be no shame in that. We act in the way we see best at that point in time, and it is a certainty that at some point we will make a mistake.

Blame

The issue is usually not that we make mistakes, but that we lay blame on others when they do, and this leads to people trying to cover up their mistakes due to the shame and pain that comes along with it. I don’t believe in laying blame, mistakes are inevitable, and if you accept that you come to realise that the only relevant question is how we improve as a result of those mistakes. In Scrum language, we need to Inspect and Adapt.

So, I try very hard to make sure I admit to my mistakes when I make them and learn from them.

Standing up

Not long ago I published this post:
https://retrospektivet.wordpress.com/2015/08/14/meeting-the-team/
Which talked about a negative experience I had when I started with a new team. It occurred to me that some people may have been offend by this post , which caused me to re-examine it and determine I had in fact made some mistakes. This was never my intention, but none the less, I feel I should stand up and say so. But being a human being I will of course also try to justify my mistakes 😉

This post was about how I perceived what happened, and that I don’t make any apologies for. But that doesn’t mean that others are expected to share my viewpoint. And when I read through it again, I realised there were many things that I did not make clear and that was unjust of me.

Inspect and Adapt

Inspect

There are a few things that when I re-read them I realised lacked the needed context.

”The team had not been informed that I would be working with them beforehand, so the first word they had of a new team member was when I was standing in front of them.”

This was not entirely accurate, most people were aware that there would be a change, I had even met some of them in the interview process. But most were not aware that a decision had been reached and that I was starting on that day. The organisation itself did feel they had informed people, which I’m sure they did, but many people made it clear they did not feel it was appropriately communicated. This was a communication problem, we should have focused on how it happened instead of trying to say why people were right or wrong about it.

”What’s more, there was a team member who had been serving as Scrum Master in a part time capacity, I was being brought in so that he could focus more on development work. Which he didn’t know until I was standing there in front of him. It actually turned out he was very upset and had clearly stated in the past that he was keen to remain Scrum Master.”

I realise now this might have given the impression that this person held it against me in some way. This could not be less the case! He was very welcoming, supportive and helpful. He was a pleasure to work with, and an all around good person. My reason for saying this was because I felt it did hurt my credibility with the team, I might be wrong about that, but that is my impression of the situation.

”This team was already very frustrated with the way their organisation was handling this transition and now I was just one more part of that problem. I am sad to say it was a blow I was never able to recover from. I worked with them for about 6 months, and I don’t feel I was every actually accepted into the team and as a result was unable to help them move forward.”

I thought about this one a lot, but I don’t feel I made a mistake here. I do feel that I got off on the wrong foot, I do think we never really recovered from it, and I did feel at the time that I was never truly accepted into the team. The team may see that differently, and they are perfectly entitled to that opinion.

This does not however imply that these people mistreated me in any way whatsoever. This was definitely not the case. They were kind and welcoming to me on a personal level, I was speaking more in the work culture divide I felt it created.

My final word on this is that I consider myself the only one responsible for our inability to move forward, if I was not able to overcome this then that is my failing and I need to improve my skills or approach to do it better the next time. I felt embarrassed over the situation and was personally not able to overcome it.

Adapt

So, what matters now is I try to improve on the situation.

That was the intention of the original post. I wanted something I could have to send to teams and organisations in the future to make sure I took responsibility for not allowing this to happen again.

This post is also an attempt to adapt, I am trying to improve on the mistakes I made by admitting it was me who made them. I will add this post as a link from the previous post. But I will not remove anything from the original as I feel that would be hiding the problem.

I will consider things I write more carefully in the future, because I honestly didn’t think of any possible negative consequences of what I was doing. I try very hard to be an open and honest person, I usually consider this to be my strongest trait. It also means I am not always good at knowing what not to say, which is my weakest trait.

Finally, I will invite anyone who was offended to say so in any way they see fit. You are welcome to comment, I will gladly make you a guest poster to write your own post disagreeing with me (anonymously or otherwise), you can call me for a personal apology, or I will happily buy you lunch and discuss it further.

Anonymity

I am always cautious not to use the names of any person or organisations as I feel it is not responsible to out anyone without their consent, as well as it being a legal question. Please respect this if you decide to comment.