In how much time will you do this?!- Project Estimation

A year and still not there yet!

As the project manager, technical architect, CTO (I’m everything built into one) sometime in 2016 I felt the pain of the development team not being able to match the goals they set for themselves. Estimations were heading north and actuals were heading south! Thus came the urge to bring my team on to the agile bandwagon since the experts seemed to say that would solve my problems.

Along came Mike Cohn and became an integral part of my life for the next few days. Learnt so much from his book Agile Estimating and Planning. I thought I had finally conquered the world! I immediately ordered Planning Poker cards from Amazon and went on the next day totally charged up to tell the team that we are going on an exciting journey from here on!

We were in the conference room sitting with yummy breakfast on the table, each team member with a deck of cards in their hands, with pale expressions on their faces wondering why are we playing a game on a fresh Monday morning ! Soon I explained things, the team started story point estimation on the user stories which I had struggled and created over the weekend. At first it took a lot of time for me to explain to them what story point meant. T-Shirt sizes, buckets .. I used all the techniques that Mike taught me to make them understand what relative estimation means! I literally had to tear them away from their habit of estimating in hours. No matter how hard I tried they kept going back to hours. Found them a middle solution where I told them they can do both. Estimate in hours and estimate in story points both for some sprints and then we would reach a point where we could slowly move away from hours to story points completely.

It’s more than a year since that lovely Monday morning and the team still estimates both! Finally after a lot of brainstorming with the Project Manager (yes, I have one now!) and a series of sprint burndown reports which showed the estimated story point line going down exponentially very neatly but the actual burndown refusing to tilt down ( in fact sometimes going in the opposite direction due to our failure to avoid scope creep) , we decided it was high time we go back to the Monday morning breakfast table and chalk things out again!

Henry Ford comforted me …

.. and so here I am comforting the team and myself that we will start again, this time with lunch included on the menu!

Let’s start all over again

Spent my weekend this time trying to do all the ground work so that I could wrap this up on Monday nice and easy! Was highly unsuccessful at trying to establish the velocity of my team earlier. The earlier sprints showed velocity of 20 sometimes and 120 sometimes (there was one which had a velocity of 0) , so averaging that would make no sense. Did some research on first sprint planning and came across a very good idea. We had to start somewhere so it was important to establish some benchmark for velocity. I had sworn I wouldn’t let the habit of hourly estimation come in. It was going to be story point estimation all the way! These were some basic calculations which gave me a starter..

Worked out some Examples of user stories and their story points (Including testing and bug efforts)

* Login – 1

* Investment Account – Personal details – 3

* Investment Account – KYC – 5

* View Portfolio – Asset Drill down – 8

* View Portfolio – Transaction Listing – 13

* View Portfolio – Bank Balance Integration – 21

This magic calculation thrilled me and gave me a good starting point and hope for a better future for my team

Developers – 4

Sprint length – 10

1 Story point – 1 hr (0.125 days)

Developer Focus Factor (meeting et al.) – 60%

Total person days – 40

Ideal person days – 24

Story points in ideal person days – 24*0.125 = 192

Story points per developer – 48

The fact that I could estimate that each of my developers (with the testers) could complete approximately 48 story points in a sprint was enough confidence for me and the team that we would pull it off successfully this time since we had some benchmark to start this time!

It’s not about you, it’s about the user story!

Some arguments and conflicts which I have faced in the past and expect that will come up on this Monday are .. “bugs take up so much time, why aren’t you letting me estimate them to.. after all the story points indicate my effort!” My answer “a bug is a slip from your end, so don’t call it your effort “.. rude but true, they got to agree! Tester says “what about my effort.. I am nowhere in the story point estimation for the test tasks that i create”. My answer “it’s about taking the user story to completion. You may include your effort in the story points estimated for that user story “. The tester also says “I will be sitting idle till these guys give me the user stories to test, and at the end they all sit on my head when their development is done, each asking me to test his user story first!” My answer “The day the user stories are defined and moved to current sprint, that day your work starts on developing the test cases for their user stories. It is possible that you may be ready with their test cases even before they finish developing it!. That’s actually the right way to go!”

At the end of it all my friends, its not about you as the developer or the tester.. it’s about the user story!

Future perfect!

So, this is what we will do on Monday..

* Move pending issues from last sprint to backlog

* Close last sprint

* Arrange user stories in order of priority for each developer

* Assign assignee, version, epic, component, estimate, due date time, story points

* For each user story create (if not exists) test task for the same and link test task to user story

* Arrange test tasks in order of priority of user stories

* Move user stories matching with the estimated velocity to new sprint

If all goes well and the Gods are by our side then , here’s looking forward to a future perfect scenario. We estimate user stories on story points always, we arrive at an average velocity over the next few sprints, we move work worth the velocity to the current sprint and away we go on a happy ride down the perfect sprint burndown chart!