Should we kill Story Points?

I would like to start with a small conversation:

Manisha: Nilanjan, do you like pizza?

Nilanjan: Manisha, you should not eat Pizza because you have very high cholesterol and you have high blood pressure as well.

Manisha: Nilanjan I extremely sorry but I asked, do you like Pizza. I know I can't have pizza. I just want to know your opinion about Pizza.

Nilanjan: OH! No, I don't like Pizza.

Manisha: Thanks for the help.

I am having, Nilanjan syndrome with most of the people, I asked,  "Should we kill Story Points?". i.e.

Manisha: Mike, what do you think about killing story points?

Mike: OH! I share an entirely different view point with story point. We are not ready because we don't know how to write story and don't know how to break stories. 

Manisha: I am aware of our situation and very well educated about the preparation needed, before killing the story points. I just want to know if you prefer having story points or not. 

This problem is everywhere. I asked more than 7 people the same question and everyone of them start with an hour long lecture. I hate to admit but people were missing the entire point. I believe, I did enough of my ranting. Lets get to actual point. 

In my mind "Story Points" are the intended to help us in estimation but we failed because of below reasons:

• We started getting in "busy-ness accounting" mode - Where our focus is burn downs and velocity vs. Value of stories.
• We start comparing teams by Story Points. It is like comparing apples to oranges. Because of that teams started dropping good technical practices like TTD or refactoring to meet their estimates.
• We started holding people accountable for their story points and forces them to spend more and more time to come up with accurate story points. This end up with lots of waste.
• I  am not going into #noestimation aisle at all.  As "Tom Demarco" said in 1982, "The most optimistic prediction has a non-zero probability of coming True". But we are still trying to make it work, is a proof that we can't do it without aligning all the stars in one line. 

I would say, Story Points are not the root issue but people are. Managers/Coaches/Scrum Masters are misusing them and giving them wrong purpose. But a team needs lot of practice and course correction to become better at using Story Points. Our ultimate goal is to enable team to be able to break user stories into equal sizes to be to focus on throughput more easily.  

We can do that by Story Points or start by teaching them, how to break the stories in equal sizes without one using Story Points?.  In my mind, with both approaches, we would like to reach the same point. I would prefer the second one vs. first.

So, coming back to my initial question, should we kill Story Points :D? I would say, Yes! No Story Points would be the ultimate reach for any high performing and continuously improving agile teams. I am confident there will never be one right way to be agile about estimation and planning. Do whatever make sense for your team. But remember, agile is a vehicle we use to reach the destination. Our destination is our product and the value, which we deliver to our customers. Anything that takes our focus out of value should be challenged and questioned.

Next blog I will share how to transform teams from Story Points to No Story Points.

Spasiba!

Manisha

are we Afraid of estimation or commitment?

"We don't do estimation because we follow Kanban".

I am sure every coach must have heard this statement countless times.  Many teams moving from agile methodology to Kanban to simply escape from estimation. As per them, Estimation is:

• Waste of time 
• Useless 
• Can be stressful
• Considered harmful 

First of all, nowhere in Kanban it says, "no to estimate". It is up to the team. I am all for challenging the status quo and questioning everything. But is estimation really a waste? I believe estimation helps teams to stay focused. High level gut feeling always helps in decision making and prioritization. So why some teams are reluctant to do estimation? In most of the cases estimation gets abused or treated as commitment. This is completely wrong. The main goal behind estimation is to size your work queue and not hold team responsible. Mike Cohn has very nice article on it.

Teams might also be unwilling to estimate when they don't understand what they are estimating. So as coach we should be able to answer "why we are estimating?" I found few technique very useful while estimation discussion. Each of these tips can be used standalone and are very detailed topics on it's own: 

• Story vs. Story Maps: Story at time does not tell the entire conversation. I found Story Maps to be more useful. Map only what you need to support your conversation. . Make sure team has discussed ways to tackle the problem at high level. ( Story Map technique). 
• Brainstorm the problem enough to consider the solution. Making sure that there is nothing better out there (always within the scope and time boxed for sure). 
• Focus on making Functional walking skeleton first. This is very important step. 
• Have a high level plan to manage your budget. Budget should lead the timeline and strategy for development. Also will help team keeping focus. 
• Create a Story Board and have in the room. 

I would suggest to keep the mind open to make sure estimation is being used in the way it is useful and meaningful.

Cheers!

Manisha