This year 2015 I have started a new stage at 47Degrees, a software development company with offices in Seattle and San Fernando, with the working environment I have always dreamed of, shelving for now my projects like Universidad Quantum until I channel this new stage. This article reflects my personal opinion about this methodology.
Among the things I am learning by practising them is how to work as a team using Scrum. The companies I have been at until now could benefit greatly from this agile methodology, in which the developments I took part in were organised in a waterfall way, that is,
the manager or project lead organised the time without taking into account the estimates given by the team.
Here I translate an article from scrummmethodology from which any team can draw great benefits by applying it in the development of its projects.
* Estimates in Scrum and Story Points.
In waterfall development, the managers determine the working capacity of someone on the team in terms of time. That is, the managers estimate how long they think a job takes in terms of time and assign the work according to the free time of that team member. This is problematic since it does not distinguish between a ‘story’ that is hard to complete and a story that does not require much effort, it only takes into account the time it will take. To put it another way, programming a new feature and organising the documents on your desk are considered as tasks that take the same time, yet there is no doubt that the first one requires a much greater degree of concentration and effort. Because of this, they should be recognised as completely different tasks that require different levels of effort.
Scrum takes a diametrically opposite approach to determining the capacity of a team member. To start with, Scrum assigns the work to the whole team, not to an individual. In its philosophy the emphasis is placed on collective effort. Secondly, Scrum teams prefer not to quantify their work in terms of time since this can undermine the self-organisation that is the base pillar of the success of Scrum. This is the biggest difference from the waterfall style: instead of having a manager estimating the time of the other team members and assigning these tasks according to that estimate, it is the team members themselves who estimate their own work according to the effort and degree of difficulty.
What is this estimation process like? Scrum does not prescribe a single way of estimating this work. What it does is delegate this estimation to the team without using terms of time, and use an abstract metric to measure the effort.
Among the most common methods to quantify this are: the use of numeric sizes (from 1 to 10), t-shirt sizes (XS, S, M, L, XL, XXL and XXXL), the Fibonacci sequence (1, 2, 3, 4, 5, 8, 13, 21, 34, etc.) or even dog breeds, in which a Chihuahua would represent the smallest story and a Great Dane the largest. What matters about all this is that the team shares and understands the same scale so that the whole team feels comfortable with its values.
During the Sprint planning session, the team sits down to estimate the effort required by each of the stories in the ‘backlog’. The Product Owner needs these estimates to be able to prioritise the tasks in the ‘backlog’ effectively, and as a result, estimate the release of the project based on the velocity. For that, the Product Owner needs an honest assessment of the difficulty of a job. So, even when a team makes the estimate jointly, actions have to be taken to reduce the influence of how a team estimates. That is why it is recommended that all the team members show their vote simultaneously. This way, when individuals «show their cards» at the same time, the voting process is like a game of poker. Some teams have developed their own decks of cards expressly for this process. Some teams call this a «planning poker round»
Despite all that, even when teams share the numbering of the scales they use, they can estimate differently. To reach an agreement that reflects the difficulty of a story, several rounds of estimation are frequently required. Veteran teams that are familiar with the process usually reach consensus in a few rounds of planning poker.
Source: http://scrummethodology.com/scrum-effort-estimation-and-story-points/
Credits: cover image obtained from: https://flic.kr/p/aehXAi with licence https://creativecommons.org/licenses/by-sa/2.0/