I measure effort, complexity, risk, and dependencies all with one number. If you don't
Things that affect story point values for me. Note that some are more about quantifying "risk" than "how long will it take?".
- how "big" is the change?
- how many parts will be changed?
- are the exit criteria vague or open to interpretation?
- is the change easy to test?
- do we have sample inputs and outputs?
- will we have to design for a tricky deployment?
- will we have to design for a tricky rollback?
- will it be hard to peer review?
- if this feature is impossible or more expensive than we thought, will we know early or late?
- is any of the code being changed extra finicky?
- do I need lots of help? code from other teams? approvals? new software installed? new hardware?
- can I iterate on this code? or does it really need to be perfect the first time?
- will we have developer 'concurrency' or 'parallelism' issues? can anyone chip in and help whenever? or is one distracted expert the only one that can do this?
...for me it's an intuitive guess at a number that flattens all that into something we can use to prioritize work and decide that work needs to be broken down more. What exactly is on that list will vary, certainly, but I would put on anything that could cause bugs, make you wait, or make you underestimate a task.
Things that affect story point values for me. Note that some are more about quantifying "risk" than "how long will it take?".
- how "big" is the change?
- how many parts will be changed?
- are the exit criteria vague or open to interpretation?
- is the change easy to test?
- do we have sample inputs and outputs?
- will we have to design for a tricky deployment?
- will we have to design for a tricky rollback?
- will it be hard to peer review?
- if this feature is impossible or more expensive than we thought, will we know early or late?
- is any of the code being changed extra finicky?
- do I need lots of help? code from other teams? approvals? new software installed? new hardware?
- can I iterate on this code? or does it really need to be perfect the first time?
- will we have developer 'concurrency' or 'parallelism' issues? can anyone chip in and help whenever? or is one distracted expert the only one that can do this?
...for me it's an intuitive guess at a number that flattens all that into something we can use to prioritize work and decide that work needs to be broken down more. What exactly is on that list will vary, certainly, but I would put on anything that could cause bugs, make you wait, or make you underestimate a task.