Current CTO exploring entrepreneurship on the side; coach; mentor; instructor.
Dedicated to promoting digital literacy and ideological diversity in tech.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.