Scrum scoring summarized
Points are an abstract representation of three things: Effort, Complexity and Risk. These are the thing that all developers should be considering while scoring a task.
Effort encompasses things like launching code to QA servers and prod, coordinating with other teams, raw programming.
Complexity is very close to effort (almost a sub-set) -- how complicated is the task to understand, will it entail changing multiple repos and the like.
Risk is what it sounds like (tasks that cover payments or upgrading systems that might break etc.)
Before scoring tasks establish a baseline of what our smallest (1 point) and largest (8 point) tasks look like (as Ben is asking). A one point task is something like a Spank the Jank ticket -- you can't get smaller than a 1 pointer.
An 8 point task is something that might take 1 or more sprints to complete -- it reflects a task that is too complex / risky / too difficult -- it warrants a larger discussion, will need to be speced out further and split into smaller tasks that can actually be done in a timely manner.
1 - 8 is based on fibonacci sequence with no zero. We can include higher numbers but there's really no need.
The other possible points within this sequence are 2, 3 and 5. These are relative to the 1 and 8 point tasks. A 2 point task should be double that of a 1 point task and so on.
Points are not currency and only reflect complexity, effort and risk -- to be clear: they are not a representation of time -- this is important. If we think of points as time we will produce inaccurate estimates that do not reflect the true nature of the tasks at hand.
Planning poker is meant to be used in order to facilitate discussion. If all developers score something a 1 pointer, and one developer scores it an 8, this reveals that the outlier either doesn't understand the task at hand or perhaps understand something that the other developers do not understand. Either way, there needs to be more discussion around tasks that are scored differently – this gives the developers a chance to fully understand the task and get on the same page.
The goal of these scoring sessions should be that of knowledge – each developer should walk away from the planning sessions feeling as though they fully understand the task at hand – all developers should feel comfortable diving in to any given task. This eliminates the need for pre-assigning tasks, increases our bus number and makes us a more flexible team.
During scoring sessions only the developers who will be working on tasks should be responsible for scoring tickets. Other parties such as product owners, project managers and the like should be present in order to explain the tasks and answer questions, but should do their best to avoid influencing the outcome of scores.
RESOURCES
" Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more. " https://agilemanifesto.org/
https://www.udemy.com/course/scrum-certification/
https://www.udemy.com/course/agile-fundamentals-scrum-kanban-scrumban/
https://www.udemy.com/course/scrum-course-udemy/
https://www.udemy.com/course/agile-crash-course/
https://reqtest.com/agile-blog/7-books-every-scrum-master-should-read/
https://medium.com/agileactors/6-essential-scrum-books-89f1fb6beb61
https://www.scrum.org/resources/blog/30-books-scrum-masters