Hello, as your role being a team lead or a tech lead, some of your tasks are to estimate the features, then its tickets. How do you do it reliably and confidently? what steps you follow?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (6)
We groom and estimate tickets as a group. The idea is that anyone on the team could be the one to pick up the ticket, so everyone should come to a consensus on what effort is involved. If people don't agree, it is a great catalyst for discussion and help everyone get on the same page. Those conversations help add additional information to the ticket.
We use Planning Poker in our grooming sessions, I recommend checking it out.
I've never used it, but I've seen it in use by people who are better than me at this stuff. Reminds me of prediction markets, a well studied way to improve estimates.
My team uses the Fibonacci Sequence to estimate tasks based on complexity.
For example, this means our tasks will be estimated as: 0, 1, 2, 3, 5, 8, 13, 21, etc.
0: no work required. Typically a meeting with another team member or some other non-development task.
1-3: ranging in effort from "almost no effort" to "a little effort", and almost no complexity. These are typically tasks that we know exactly what the problem is ahead of time. We just need to go in and fix it.
5: reasonable effort, and low to moderate level of complexity. These are usually tasks where we have a high degree of confidence in what the issue is, but aren't 100% sure ahead of time.
8: typically reserved for new work, with a high degree of complexity and many unknowns. Things like new features that require R&D, or obscure bugs will end up in this category.
13+: very high degree of complexity, very high degree of uncertainty.
We never schedule anything higher than an 8 within a sprint, and we never assign more than one 8 to a person per sprint. Our sprints are 1 week in length, Monday to Friday.
Anything higher than an 8 must be broken down into components that are smaller. A 13, for example, might be broken into an 8 and a 5, and scheduled like that. Or maybe two 5s and a 3, etc.
We've determined that someone can usually comfortably complete 22-25 points per sprint.
We specifically estimate tasks based on complexity instead of time because we find time to be too inaccurate a measurement. Complexity also translates better for individuals to understand, and takes the pressure off of having a clock on my team, which I thoroughly dislike.
I just multiply the "points" by 100.
Estimates can become more honest, because no one needs to worry about looking impressive when their estimates are viewed out of context.
"Oh, yeah, as you can see here, Mr.
<drive-by-person-with-no-basis-for-comparison>, Brad has finished 100 points this sprint."can you explain more about "multiply by 100" ?😄
No. Why shouldn't I take the secrets of the 100x developer to my grave?