## Why is estimate based on story point much BIGGER?

Many times, we need to provide estimate the cost of a project/feature. For many Agile teams, it will be done by using relative estimate, e.g., story point and convert it to cost based on team’s velocity, like the following formula.

Total # of Sprints =Total Points / Average Velocity
Total Cost (\$) =Total # of Sprints * Team’s cost per Sprint

Recently, one project team’s manager asked me why the cost estimate based on story point and velocity was 3 times bigger than the estimate based on effort (man day). When I checked the two estimates, I realized that the project manager convert effort estimate to cost directly, like

Total Cost (\$) =Total Efforts of Many Day * Cost per person per day

The problem of this formula is, usually the cost model of a project is based on duration rather than effort. That means team may spend 3 days to finish 1 man day work so that the cost will be 3 days’ cost but not 1 day’s cost.

It is a common problem that people will convert effort estimate based on man day to the estimate of duration and schedule directly. That’s why I don’t like effort estimate because it is so easy to cause confusion about it.

With my experiences, I found story point estimate is actually quite accurate and easy to apply. Because it is relative estimate based on comparison. And according to the research of scientist, human’s brain is really good to compare rather than measure. That means when team considers that one story is roughly 2~3 times bigger than another one, the relative size does make sense most of time.

And the effort estimate (man day) is trying to estimate the effort of each activity, e.g., analysis, development and test. This kind of estimate usually requires more details about the requirements and the solution in order to improve the confidence. It will take longer time and also the deviation will be often big.

When the estimate needs to be converted to duration and cost, the conversion rate for story point is team’s velocity what is the actual data represent the team’s capability at the moment.

And the conversion rate for man day effort is based on general experience rather than team’s capability (except team measure it which is quite difficult and usually will create too much overhead to the team according to my experiences). With that, I believe the estimate based on story point and team’s velocity will provide more accurate forecast about the project.

So when you already have the estimate points and team’s actual velocity, it will be quite easy to estimate the duration and cost. If you find the figure is quite big, usually it is because team’s capability, what is velocity, is not as good as you expected rather than the size of the work has been overestimated. So to reduce the cost, you need to think about what can help the team to improve capability rather than ask team to reestimate again and again.

## Stop talking, start doing

I used to be involved in the project what was a very challenged project because neither business needs nor technical possibilities were clear.
According to the organizational project initiation process, the business stakeholder asked for estimate about the potential requirements so they could apply for the budget. So, we tried to help the team to do the relative estimate using story points. But after 4 workshops, the business stakeholder still thought the cost was too high and couldn’t accept it. And the project manager would like to organize more workshops to investigate further and hope it would help the team to come out more “reasonable” estimate.
This scenario might sounds very familiar to you. The business probably has already had an acceptable range of budget figure in his mind for his very vague requirements. And team normally will provide a bigger number because of very limit information. Then it will be the dead loop of conversation. Business expect s smaller estimate and team always give even bigger one. And in the most of cases, it will end when team feels tired of this game and surrender themselves to give whatever the number the business expected. But, of cause, the business will pay back when they spent more money and received a crap software at the end.
So, how to escape from this trap? In this case, I asked project manager, if it was possible for the business to sponsor team for 1~2 iterations to start to work on something what were relatively clear and feasible. So everyone would have better understanding about the complexity of the project and then business could decide if it was worth to continue accordingly. I also mentioned that, with total about more than 8 hours workshops what involved many experienced team members, we already spent a lot of money on estimate but couldn’t got any confidences.
At the beginning the project manager was not quite sure if it was a good idea but he agreed to give it a try. And, guess what? The business accepted it and we stopped to provide further estimate but started to plan for the first iteration. During the iteration planning session, we worked with business stakeholders together to decide the possible delivery of the first two weeks and they were very happy about it. At the end of the planning, one of the business stakeholders said: “I am very happy that we finally start to discuss about some detail instead of all those big epics. And thanks to everyone to make this happen!”.
This is a quite common scenario in my experiences. Customers expect the lowest risk for their investment and, at the same time, maximized return. Both of them are fair. The question is how to do it. The traditional way is trying to do lots of analysis at the beginning and expect that will reduce the uncertainties so that we may put everything under control. But the reality is, most of time, through those early stage investigation, we probably can only find the answers of what we know, but, like the following diagram,

There are other 3 areas where the most of uncertainties stay, we need to Explore, Experiment and Expose. We won’t be able to find the questions’ answers in those 3 areas until we start to try. The earlier we start to try, the earlier we start to learn and reduce the uncertainties. That is the only way to reduce the risk and maximize the return (or minimize the waste).
Stop talking and start doing. Start to deliver values to customer and learn from it earlier. The customer will appreciate it.

## Don’t fight but help middle managers

More and more organizations have started to transform themselves to be more Agile/Lean organization, through the way of bottom-up or top-down and start the journey through pilot team or product. And the outcome were very encouraging. Then the organizations started to try to scale the success to all the other areas. Then it seemed not as good as we expected. Teams started to feel even more suffer. When you started to look at the situation closely, usually you will find something like

• People managers are keeping on shuffling team members across different teams to try to keep “high utilization rate”
• Project managers are forcing teams to do more
• Managers prefer to have more specialized team instead of cross-functional team

And when you tried to communicate with those middle layer managers about Agile principles and values, you got resistances from them and then the transformation was stuck. It likes a trap in many organizations’ Agile transformation journey.

So how to break this glass ceiling? Should we treat it like a battle between the change agents and middle managers? We may try to fight back. We may try talk with top managers to force things happen. But in most of cases, we will lose. WHY? Because this is the wrong strategy and push everyone to the corner of “live or die”.

Regardless of the professional background, we are all human being. Middle managers are all good in person. Some of them even can become good friends of life. So, use this empathy, let us think about, why middle managers believe that they are doing the right thing? For example, why people managers shuffle people cross different projects all the time? Will they really enjoy it  and value it? I personally don’t believe it. At least, most of the people manager won’t like it. But if the organization operation is more cost-driven rather than value-driven, it will force the people managers to pursue high utilization rate because it will reduce the cost. Even they don’t like it but their personal performance will rely on it. If we could understand this, treat people managers as blocker is wrong. We need to find a way to change the organization’s value system. So the performance is rely on the value delivered by the team rather then how busy people is. This will help the people managers to focus on more value things instead of working on spreadsheet to tweak the percent of people allocation.

Also, many times people resist new ideas because their previous success experiences make up their beliefs and some of them are not fit for the new development needs. But they haven’t been aware of it yet. So we need to help them to build that awareness, this is the first step of change (please refer to ADKAR model). To do that, we may start from their current pain points and try to help them through different approaches. We may also invite them to participate some forums or conferences to see the different world. We may also try to connect them with their buddies who have good experiences about Agile. Or, we just wait until they start to knock the door and look for help.

In conclusion, as a coach, our value is to help organization to be Agile. This also include to help people to have better and more value life. We need to help middle managers to be aware of the needs of change. Because this will let them to have better life.

## Ask extreme questions

Recently I’ve been involved in a conversation with a business analyser who is passionate of Agile but still need time to understand Agile values and principles better. The conversation is about how to get the business requirements.

At the moment, team is struggling to keep the stories to align with business values. And also because of the complexity of the system, team is also struggling to see the whole picture. So, in order to help team to shape the product backlog, this BA was keeping on asking the product owner to provide business requirements. And the product owner felt very difficult to do that because of uncertainties. When I’ve been involved, I asked BA why she required business requirements because everyone interpreted that request as specification document. She said that would help the team to see the whole picture. And then I asked her what kinds of artefacts she expected to get, she mentioned about some documents on company’s wiki site. Then the conversation became difficult when I tried to explain that the best way to communicate the detail requirements is to engage the team to have the face-to-face conversation with business stakeholders. And the documents can be used to capture knowledge/agreement we get from the conversation. She appreciated my point but still considered the document were mandatory before engaging the whole team in a conversation.

I felt a little bit frustrated about the conversation till a question came to my head. Then I asked her, “How will you get the requirements if the only tools on hands are just pens and paper and there were no computers, wiki, MS Word and etc.?”  She said “I will write them down on paper”. Then I asked “How many pages do you expect to write for that document?” She said, “Just around 2 pages with some bullet items list about the requirements.” From then on, the conversation became more easier because she agreed that those bullet items were quite like user stories and we could create user stories and set up story mapping to help the team to see the big picture.

What I learnt?

First I should not assume the term of requirement document is about big upfront specification documents. Sometimes people will use some terms they are familiar with to explain the different things. I should verify it further about what its exact meaning is.

Second, it is quite usual that people will try to solve a problem with their previous experiences. Use some extreme questions will help them to think about alternative ways. For example, team might feel it is very difficult to get things done in a timebox iteration, questions like “How will we showcase to business in one-day iteration?” will help the team to think about what are the wastes in current process and how to eliminate all of them.

## Why I installed Spotify on my phone

Today I downloaded Spotify to my Nexus 6 finally. Actually I haven’t really want to install another music app previously because I have had one -NetEast Music which is also a very good music app. So why I finally installed it today?

Today I received an email from another coach about how Spotify organized a great hackthon successfully (Diversify – Creating a Hackathon with 50/50 Female and Male Participants),  in that blog, there is a playlist link of all the musics added by that hackthon’s attendees. As a music lover, I opened it in Spotify web player, and then because of curiosity I entered the home of player. When I went through it I found something that really caught my eyes what are the music categories based on some life scenario, e.g., Dinner. Why it is so attractive to me? Because every time when I tried to play some musics during the dinner time with my family, it always a little bit challenge to me to find proper one especially that we don’t like to listen to the same playlist all the time. This feature, which Spotify provided, is exactly what I need and driven me to install it on my phone immediately and I will give it a try tonight. It is so impressive to me for this feature. I think the product owner of Spotify must be a very insightful person and they can dig the customers’ real needs from very small things.
Lot of time when people are talking about innovation, it is always about some BIG ideas, something that can change the whole world. But most of cases, the succeed innovations are from small changes. The change that can make people’s life better. Apple which might be the most innovative company in recent decade is not the one that invented the mp3, mobile and touch screen. But she is so successful till now is because she make it so simple and easy for people to play with it and make it a lot of fun to use their product. Also even more important, to make people feel different with others.
Innovation needs empathy and insights for humanity. To be innovative you can’t just look at the world with your eyes but more important you need to connect the world with your heart.