If you use a Scrum Sprint/Kanban hybrid system, it is possible to get a more accurate estimate of time. As a project manager I use to rack my brain trying to figure out how to use the Sprint or Kanban style to accurately give estimates. This system requires about a month (or 4 sprints) with of data, before it start to become useful, however in my opinion, pretty accurate.
Most of the developers were pretty good about giving a gut feeling on difficulty on a specific task, but awful at giving an accurate time frame for completing the job. So what I would do is ask the developers to break down a user stories (any task they marked as a 13), then go down the line and assign a difficulty 0, .5, 1, 3, 8 or 13; except I made the numbers more subjective in name,
- "Very Easy" (0 can be done less than 5 mins),
- "Easy" (.5, is a simple task), "small" (1, This task isn't difficult, requires other tasks be done first or time to develop),
-"medium" (3, this is a moderately difficult task, requiring r/d and time to test)
-"large" (8, this is a very difficult task that requires many hours of coding or testing or implementation)
The above titles per task are very subjective to the team of developer or individual developers as a whole. PM or Scrum Master should ask the collective to get an average on difficulty of task, based on who might be assigned the task or how much everyone agrees on the difficulty. Once you've marked the tasks and they've been assigned, you can now take subjective data and mark it against real data, creating objective data that you can use for estimates.
After 4 weeks (or sprints) of tracking time against each ticket, each developer and each team, you can start to pull data that will allow you to give time estimates. For each team and developer you end up with their averages (overall isn't as important as it is per difficult task), which will allow you to gauge how long a specific task or set of tasks will take.
Example:
This last week Bob completed the following number of tasks and it took him 40 hours to do so.
Last week:
Tickets
Easy: 6 Hours: 2
Small: 5 Hours: 7
Medium: 3 Hours: 16
Large: 1 Hours: 15
2 Weeks ago:
Tickets
Easy: 2 Hours: 1
Small : 7 Hours: 9
Medium: 1 Hours: 5
Large: 2 Hours: 25
Bob's Averages (time spent) per task size; rounding up:
Easy: (20mins+30mins)/2= .5hrs avg
Small: (84min+77min)/2= 2hrs avg
Medium: (960min+300min)/2= 11hrs avg
Large: (900min+750min)/2=14hrs avg
(the more data you get per week, the more accurate these numbers will be over time)
As you can see we have some averages for Bob's estimates, which gives us a basis for giving rough time frames. I found this to be quite effective, because some tasks that get marked Medium or Large end up actually being Small or Easy. When creating estimates, I error on the side of rounding up and depending on the developer and how many of each type of task assigned, will add 10-20% more time.
So if Bob has 15 tickets assigned to him, which are all Large difficulty and Bob only works 40 hrs a week, it will take him 5.5 Weeks ( 210 hours) to complete, provided he only works on those tickets. Now practically speaking, I'd NEVER assign that many tasks to one individual, but wanted to give an example of how this can benefit you. I alway try to Under Promise, but Over Deliver. I find this method gives a great metric for estimations and Managers alike. If a solid developer is starting to struggle and needs help or is distracted, we can now see numbers accurately.
Hopefully this makes sense, but I welcome anyone to reach out and ask questions.
