Working on a project can be refreshing or tiring depending on whether the participants are on course to deliver the outcome on time and budget or not. This also affects the quality of the output and directly on the confidence of the team on their best efforts. Honestly, estimation of work load in the back log can be pretty difficult. From experience, I have learnt that even in a team where members have an almost equal level of knowledge, this becomes tricky.
When you have an epic comprising of several stories, and they have to be estimated, there are several factors to be considered as we will see.
Managing the estimates: When the story points have been created, planning their estimates should be done using the number of powers of 10 that it is expected to take. This is commonly referred to as order of magnitude. This is commonly so because human beings are good at figuring out whole numbers but then the memory fails beyond that. It is easier to estimate the complexity of a story point this way, as it is in the human nature to easily understand it. As a story point starts to be worked on, the team easily relates to the velocity since the estimates are manageable. One of the most common misconceptions when working with agile is that teams tend to view estimation, not in terms of complexity but in terms of the duration it takes to complete the tasks. Estimates planning can be done using several methods including, Fibonacci, T-shirts and Powers of 2. Recently there have also been more people starting to use Modified Fibonacci which is a variation of the older Fibonacci.
Estimates should be done in relative terms: Tasks in a story point should be estimated in relative terms rather than absolute terms. This has an advantage of creating mindset network but also helps to set the right pace for the team. For instance, the team could estimate that it will take twice as much effort to design a wireless network compared to setting up the firewall of a company. Typically, the best way to approach this is to start with a fairly small task that the whole team is most likely to have an agreement on its estimation and then use it as a reference estimation point. It could be the case that the team agrees that configuration of mobile devices is a 2. A task that takes five times as long will then be estimated as a 10. This does not bind the work to be done within a specific period in terms of hours or days, and also helps the team to understand the workload relations of the two tasks. Moreover, teams are able to make estimations faster since there is better abstraction from the details of the task which doesn’t require estimates add up. And as already mentioned, the team gets to see the velocity with which the sprints progress.
Estimation by story size: Working on different projects, I have learnt how difficult it can be at times to get the right size of a story let alone get its best estimate. Recently I worked on a project where I was asked to estimate the period it would take to complete the project. Apparently, it turned out that while I my estimation was very different from the project manager’s. And the source of the difference was our perspectives to the size of the stories. To avoid such recurrence, it is good practice to at times use bucket backlogging and not estimate all the story points. Quite often, when estimating with the rest of the team, we use the Fibonacci method where the sequence 1, 2, 3, 5, 8 and 13 are applied. Depending on the number of story points and the sizes, we are then able to choose for instance, 3, 8 and 13. These are referenced to as buckets. The stories are then estimated on whether they belong to the 3, 8 or 13 bucket. Over time, the team has embraced this method as it does not put so much pressure on team members to achieve perfection rather on completing the estimation task. This keeps the whole team focused and engaged on discussions.
Different team members use different approaches to estimate the workload on their backlog. As PMI states in PMBOK, estimation should take into consideration severalcriteria including duration, cost and resources. I would like to see how other teams estimate their work load
Project Management 