One of my client was struggling with a huge backlog. His teams were not able to prioritise their tasks. The estimations were going haywire and productivity was low. The concept of story points (used in Agile Technologies) did not help them much as it was too abstract for them. Each story or task was different and hence they were not able to relate them in levels of difficulty. Because the idea of story was abstract, it was also not easy for them to compare stories with same points in different sprints.
Then I developed a framework to understand the stories and improve time estimations. The three parameters used were
- Understanding of business needs
- Complexity of tasks
- Difficulty of task and volume of work
The easiest tasks to estimate are the ones that are fully understood both in terms of what the customer wants and in terms of steps to be taken to complete the tasks. A task where the customer himself is not sure of what he wants or a technical task for which the engineer himself is not able to develop a road map would need more time in analysis. Either way the estimations for the time would be way off. Effort and time would be required in analysing and breaking the task into smaller tasks or sub-tasks.
Once the tasks are understood and broken into task with steps needed to accomplish it are defined, the estimations would be a function of difficulty and volume of work.
It works actually like story points does in Agile. The stories can be placed on matrix based on story points. It would be easier to develop time estimates for stories with lower story points and hence they are prioritised to be picked up. The above model can also be used for prioritising projects in case of a clogged pipeline. The teams would also be able to compare stories across sprints based on difficulty level.
Please do wait for an illustrated example of this in next blog post.