What are story points?
Firstly, Agile estimation is the process to estimate the effort required to complete a task.
A story point is an arbitrary measure of effort required to implement a user story; it's a number that tells the team how hard the story is. “Hard” can be related to complexity, unknowns, and/or effort.
Story Point values are based on a Fibonacci sequence (1,2,3,5,8,13,21,...)
Story point estimates should take into account technical complexity & effort to complete.
Story point estimates should account for the total effort to reach done, not just code complete. Both code review and QA testing can take considerable time and should be accounted for.
The lowest point value that can be assigned is 1, don't dabble in fractions of a story point.
Stories with an estimate larger than 8 should be refined and broken into multiple stories.
Time spent on different parts of the development process should be measured in hours & days.
When in doubt about the value of a ticket, play conservatively and go with the higher value.
Breakdown by Time Spent
The table below is provided as a guideline of the total effort put forth during Development, Code Review, and QA testing for a given point value. Duration values are shared as uninterrupted/distraction-free time; time spent on a ticket may exceed the value shown due to switching context throughout a given sprint (meetings, shifting priorities, etc)
The Process of Story Point Estimation:
Step 1: Choose an estimation matrix (Fibonacci series).
Step 2: Identify user stories or other relevant items for estimation.
Step 3: Select reference points using prev. experience.
Step 4: Identify the risks, size, and complexity of the selected estimation item(s).
Step 5: Discuss and estimate.
Step 6: Set up deadlines
Story Points are Not,
- Estimate of time Very difficult to estimate time, hard to get right Story points trade off precision to make estimating easier
- Exact end dates
- Exact time spent
- Time tracking
- For comparing the team's output Story points are, by definition, relative and unique to each team
Thus, comparing one team's velocity to another team's velocity is pointless(pun intended)
For in-depth details about Scrum: [https://scrumguides.org/scrum-guide.html]
Oldest comments (0)