The value you can get using Story points is not worth the energy or the value you can get from it.
Instead, as an alternative, I would encourage slicing complex tasks into small tasks as much as possible, so in the end, you end up with work of (let's imagine) always 1 SP, so counting SP does not make sense anymore, but rather tasks and the value behind them.
Additional resources:
- 1.- Agile Estimating (has an EVIL side-effect)
- 2.- The BEST part of Agile Estimating. And how to get rid of it.
- 3.- Agile Forecasting... WITHOUT Estimates?
- 4.- It's time to stop the madness. It's time to stop estimating
TL;DR: Smaller Stories. Going small is everything. Aka: Story slicing.
#NoEstimates
Good estimations help us to achieve the best possible efficiency within our team and greatly help our Product Managers in the sprint planning process.
Estimations can be done in different ways. You can estimate time or complexity.
In my personal experience, I would prefer to estimate complexity, because it helps to pop up the unknowns and uncertainties that each individual of the team has.
Use fibonacci numbers. This makes it easier to distinguish between complexity levels and to reach a relative estimate rather than a specific "complexity score".
By estimating tickets constantly teams can over time gather insights on their performance and get a lot more realistic idea of what they can achieve per sprint.
Even though story points are kind of arbitrary in nature, I will try to give an overview of what they mean to us in the next section.
The most basic and least complex kind of task. Is usually achievable in less than a day by one person without consulting others or doing any kind of investigation. That change must be straight forward.
example: Changing a few simple lines of code in few files.
Still, easily achievable without any kind of investigation but requires a bit more professional effort/ knowledge to finish.
example: Adding a new field in an existing API resource.
A task that requires a certain level of knowledge or investigation to solve but will be pretty straight forward for a person that is knowledgeable within the specific system/s.
example: Adding a new configuration to a system by reusing and changing existing code.
This task/problem may involve multiple systems and/or substantial investigation in order to complete it. Will most likely take more than a day and usually it requires a decent amount of implementation work.
example: Doing a deep investigation in the system with multiple stakeholders and important functionality involved (even if fix is easy in the end).
A complex task that involves multiple levels of substantial complexity e.g. different systems, uncertainty, lack of knowledge, code complexity, etc. Will definitely take multiple days and could also usually be split in sub-tasks.
example: Implementing a new complex logic in multiple systems.
This task has an almost unforeseeable amount of complexity in multiple areas and will take an unknown amount of time. To many factors of "uncertainty/unsureness" are involved.
example: Investigating a new technology and drafting a concept without knowing if it's even feasible within the system.
This basically means the ticket has been poorly defined and should be split. It is not recommended to use 21 points (or higher) in estimations.
- Clean Agile (Amazon) [English] by Robert C. Martin