joe-dev-public
commented
2 years ago Good point that having absolute time estimations could make people feel a bit stressed if they're taking longer! Luckily I don't think we paid much attention to the estimations while we were working. 😄
It's probably not clear from our use of labels, so it might be worth me explaining our approach. It was a bit like this:
- Write as many user story issues as we could think of.
- Make a rough decision about which ones we wanted to try and tackle in week 1. For those issues:
- First pass: "relative" complexity estimation (t-shirt sizing).
- Second pass: "absolute" time estimation (E-numbers, where the number is just the number of hours. No Fibonacci here :)
- Hard to estimate, of course! But thought it was worth a try after in-house project. (It didn't make sense to estimate team capacity in relative terms.)
- Always over-estimate, and then add a bit more. 🙂
- We didn't manage to give every issue an absolute estimate.
- Estimate week 1 capacity in absolute time based on schedule
- Roughly 20 hours, taking breaks into account.
- Plan is to work almost exclusively in pairs, so we have 2x20 = 40 hours of dev time (not 4x20 = 80).
- Adjust week 1 goals if it looks like we've got too much/little in there.
- i.e. add up all the E-numbers, and if they're over 40, we've planned to do too much. (I think we settled on an E total of roughly 35? Felt like it would give us some margin for error!)
- While working, I tried to keep track of how much absolute time we actually spent on each issue.
- It's incredibly easy to forget to do this, and/or to mix up timings of different issues. So not much useful data was recorded. 😉 Trying to backfill during sprint review now.
sonianb
I noticed in your issue backlog that you're using both Fibonacci Scale and T-Shirt Sizing for Agile Estimation. Maybe using just one method (with a Kanban board) would make the estimation process easier?
Also, I saw that in the label description, you added an estimated dev time. This is something I did in the previous projects as well and it took some time to realise that estimating tasks based solely on complexity (E1, E2, E3, etc.) rather than hours can benefit the team and remove some of the stress that comes with spending too much time on a task that was supposed to take an hour or two. I think it'd help if you estimate the stories/features based only on their complexity rather than the time you think it might take to complete them.
Hope that helps!