JUST IN TIME ESTIMATIONS

JUST IN TIME ESTIMATIONS

Estimating User Stories using Story Points is a very popular method used by agile teams to estimate the User Stories based on size and complexity and it perfectly suits the agile teams.

Does Story Points help teams to know how much time would they need to complete a particular User Story or a Task?

I know most of you would say NO. Then what helps the team to forecast their work completion schedule? We Shall come back to this in a bit.

If Story points doesn’t help teams to estimate their tasks, then why do we need story point estimations?

Any guesses? Would you believe if I say the story points are just a gateway for considering the User Story for the sprint planning.

Yes, Story Points act as a parameter for understanding the complexity of a User Story to determine if it can be completed within a Sprint.

I keep hearing frequently that some agile teams have the practice of converting the User story Points into hours say 1 Story point is equivalent to 8 hours or 1 day or so.

I personally don’t encourage this practice as it destroys the concept of story points and provides a false sense of accuracy.

This also leaves us with a thought that if you are converting Story points to hours what would be the point in having a Story Point estimation which is just an overhead to the team.

Let me explain the importance of Story Points in Agile through an example,

We all have been to the movie theatres to watch a movie (Though Covid had stopped us for a while 😀).

We buy tickets at the counter and while entering the cinema hall, we handover the ticket to the person at the entrance and he tears the ticket apart and lets us into the Movie Hall.

Once you are in the movie hall, have you ever worried about the ticket? No.

Why because the Movie ticket was needed just to gain entry into the Movie Hall and once we are in, we seldom care for the ticket.

Let’s now co relate this way-Movie ticket to be the Story point and the cinema hall to be the sprint backlog and the audience itself is a User Story.

This example helps us understand that Story Points are needed for the User story to be considered for Sprint planning and added into the Sprint Backlog. Once the Sprint backlog is created, we wouldn’t actually need the story points and from there on it’s a different story.

Hope I made sense.

Going back to the actual estimation Process, the example made us understand that the story points are just an entry criterion for sprint planning.

Now let’s come back to the topic in focus for today.

What happens to the story points once the story is added to the sprint planning?

If your team is relatively new to agile, I would advise to hide the story point field of the user story to not confuse the team with hourly estimates and story points.

Let’s see what happens to the user story once it’s added to the Sprint backlog.

Once a user story is added to the Sprint Backlog, Team splits the user stories into smaller chunks called tasks (formally in a task out session post sprint planning) and they estimate the tasks in hours which is common across all the agile teams. Teams may use different techniques to arrive at the estimation of tasks and most of the time it’s a ballpark estimate (rough figure).

Even though the teams have sliced and diced a user story into smaller chunks and estimated the tasks, there is always a probability that the actual effort consumed would be nowhere near to the estimated effort.

I still don’t deny that estimates are still an estimate as the word itself states and cannot be the actual figures but would've expected to be somewhere near to the actual effort consumed.

This high scale of Estimated v/s Actual effort mismatch would make the team feel that estimations are just numbers to fill in the field and doesn’t have any significance as they always deviate from what was consumed.

This under/over estimation leaves us with a series of questions:

1) Are the teams estimating the tasks correctly?

2) Does the team have sufficient knowledge on product and would need a few refresher sessions?

3) Do they fear being held to an artificial deadline that can impact the quality of their work.

4) Do they think they are answerable to the management if the numbers of the tasks look big and many more.

Let’s think about the possible ways to overcome this problem.

1) Ask the experts/experienced to estimate the work but it may not hold good if a newly joined team member is working on the task estimated by an expert due to varied experience level.

2) Revisit the estimation techniques to evaluate the gaps in the current estimation process and adapt a suitable one that works for your team.

3) Encourage teams to consider contingency efforts while estimating.

These are the legacy methods which would help teams improve the estimation.

While thinking of some innovative ways to improve estimation, I thought a better estimation can be achieved by breaking the task to the Most granular level (slicing it as much as possible) and let’s call it as JITE (Just in Time estimations).

The JITE Technique is all about considering all the possible Sub tasks needed to accomplish a particular task at the granular level and estimating each Subtask.

It’s easier to estimate a task which focuses on a single thing and easier to predicts the underlying risks at that point in time.

I agree that the board may be flooded with tasks but trust me, estimating tasks would be fun with some benefits as below.

1) It increases the morale of the team as they start accomplishing smaller tasks within the estimated time.

2) It creates a Transparency as board depicts the actual status of a task and a better insight.

3) Helps to identify the impediments at an early stage.

4) It gives a better insight about the task to anyone who is viewing the board.

Let’s take a layman example of constructing a room for estimation.

Below picture of the Sprint board shows the tasks estimations with and without the JITE technique.

Estimating the high-level tasks

                                                                     Figure 1: Estimating High Level Tasks

There are different activities for constructing a house and the estimation is 10 days (the picture says its 10 hours because the board is designed to display in hours).

The Estimations look Pretty descent and realistic at the moment.

But let’s apply our JITE technique to break down the tasks into much granular chunks and estimate them.

Also compare the estimations to understand the variations.

This is how it would look if we had to split the tasks of house construction into its lowest hierarchy.

                                                     Figure 2: Estimations using JITE Method

We See that there is an estimation using the JITE technique has 2.5 days more compared to the estimation done for the high-level tasks.

Wasn’t it easy and insightful to estimate the simper tasks with a specific purpose  than estimating a high level task

Hopefully this helps us to understand that its easy to estimate the smaller tasks and the estimates would also turn out to be realistic

Trust me, this method would just disrupt your tracking metrics like burndown if you were tracking it as Days against the Task efforts as you would have a lot of scope creeps.

But that should be ok as metrics should help the team progress in the right path and should not be a tool for measuring the performance of the team.

I have started encouraging our team to practice this technique and things seems to have improved. I would come back with a success story soon.