July 14, 2010 at 16:52Scrum requirements assessment
I will talk about the assessment of work (assessment) in the Scrum. It is recommended to carry out it twice - first in story points , at the user stories level , and then - in hours , at the level of tasks in the current iteration. I will also try to explain why this is done twice.
At our company, we decided to take the introduction of Agile principles more seriously , and Scrum as a concenter . I was assigned to implement this business in a small project, which should be ready by September, with 4 programmers and a web designer. The task of the project is the migration of the html site in Sharepoint 2010, and the addition of many new features.
We used to think that the morning Scrum rally was already such a normal scrum. But after reading a little and digging around, it turned out that in general, not quite.
So, the initial assessment is guesstimate. The
initial assessment of the project is carried out at the user stories level which are in the Product Backlog. User stories are recommended to be written in a slightly non-grave, at first glance, manner:
“As a [type of user] I want [some goal] so that [some reason ]).
For example, instead of the usual “The student should be able to choose the desired course” - “As a student, I want to choose the desired course to get the necessary knowledge.” On the one hand, it sounds very artificial, but on the other, both the programmer and the business representative understand who wants to do what and why. In a short sentence there is a context, a role, an action and a goal, always in the same structure. Conveniently. Though unusual.
My backlog consists of 40 stories of this level. These are not detailed requirements to make accurate estimates, but something can be done to evaluate the backlog in story points.
What are story points? This is a relative assessment of each story. The theory suggests using a power of two to estimate (2, 4, 8 ...) or a Fibonacci series (1, 2, 3, 5, 8 ...).
In order to evaluate, you must first select the system, and the maximum value. We decided to use Fibonacci, with a maximum value of 21.
Next, we need to choose the simplest story and evaluate it as 1. In our case, this is the story - “As a user, I want to view information about the trainers in order to know their competence”. After that, we select the most difficult story, and evaluate it as a maximum, in our case - 21. This is the story “As a subscriber, I want to book a course so that I can attend it”.
After that, the theory suggests evaluating the remaining requirements, in order of priority. To do this, you can use a technique such as “Planning poker”, where each programmer writes his own assessment of the requirements on the sheet, and then everyone shows them at the same time, and the discussion begins if the ratings are very different.
It is not necessary to evaluate the entire backlog - it is enough to evaluate only the stories several iterations ahead. In addition, it will be necessary to return to this assessment, because the backlog is constantly updated, priorities change.
So why are story points, not days?
Firstly, at this stage not much is known about the requirements to carry out accurate planning.
Secondly, programmers will not want to evaluate such requirements over time, because then you will remember them ... It is easier for them to answer the question “Is this so big?” than "how much will it take?"
Thirdly, in our case, the team is not familiar with the technology (Sharepoint has just left), and it is simply impossible to give accurate estimates.
What is the use of it?
First, a product owner can reassess its priorities. Since the story A “costs” 13 points, and B is just 2 - let's make it soon.
Secondly, it helps planning. If we know that in the first sprint we made 50 story points, in the second - 55, then in the third we’ll probably do 55 as well
. Thirdly, it's easier. “A” is more difficult than “B”, therefore 21.
And what next? Where are the normal numbers?
Ordinary man-hours start later.
The first sprint is the most difficult, especially with us, with a new team, new technology and a new methodology. Together with the product owner, we identified 9 stories for the first iteration.
For an accurate assessment, we sat down with the most experienced programmer, and given the lack of experience with the rest, we evaluated. In a normal way, and here it was necessary to play poker, but the situation is not the same.
To get accurate grades, each story needs to be broken down into tasks. Each task should be no more than 8 hours, so that in a day it would be clear whether it was done or not. We divided our stories into 2-10 tasks, about such as “Build a UI for the page of trainers”, “Prepare a list of trainers”, etc. We rated each in hours, and it turned out ... What do we need 3 times more time! Had to reduce the backlog of iteration.
As a result, we got that in the first iteration we can finish 67 story points. This is 105 hours of work. That is, now the speed of our team is 67 story points per iteration. As the team becomes familiar with the new technology, speed will increase, and in the next sprint we will be able to develop more story points. Using the estimate in hours, this would not be possible, or it would be necessary to invent some formulas, such as there, “in each subsequent iteration we plan 10% more than in the past.”
At our company, we decided to take the introduction of Agile principles more seriously , and Scrum as a concenter . I was assigned to implement this business in a small project, which should be ready by September, with 4 programmers and a web designer. The task of the project is the migration of the html site in Sharepoint 2010, and the addition of many new features.
We used to think that the morning Scrum rally was already such a normal scrum. But after reading a little and digging around, it turned out that in general, not quite.
So, the initial assessment is guesstimate. The
initial assessment of the project is carried out at the user stories level which are in the Product Backlog. User stories are recommended to be written in a slightly non-grave, at first glance, manner:
“As a [type of user] I want [some goal] so that [some reason ]).
For example, instead of the usual “The student should be able to choose the desired course” - “As a student, I want to choose the desired course to get the necessary knowledge.” On the one hand, it sounds very artificial, but on the other, both the programmer and the business representative understand who wants to do what and why. In a short sentence there is a context, a role, an action and a goal, always in the same structure. Conveniently. Though unusual.
My backlog consists of 40 stories of this level. These are not detailed requirements to make accurate estimates, but something can be done to evaluate the backlog in story points.
What are story points? This is a relative assessment of each story. The theory suggests using a power of two to estimate (2, 4, 8 ...) or a Fibonacci series (1, 2, 3, 5, 8 ...).
In order to evaluate, you must first select the system, and the maximum value. We decided to use Fibonacci, with a maximum value of 21.
Next, we need to choose the simplest story and evaluate it as 1. In our case, this is the story - “As a user, I want to view information about the trainers in order to know their competence”. After that, we select the most difficult story, and evaluate it as a maximum, in our case - 21. This is the story “As a subscriber, I want to book a course so that I can attend it”.
After that, the theory suggests evaluating the remaining requirements, in order of priority. To do this, you can use a technique such as “Planning poker”, where each programmer writes his own assessment of the requirements on the sheet, and then everyone shows them at the same time, and the discussion begins if the ratings are very different.
It is not necessary to evaluate the entire backlog - it is enough to evaluate only the stories several iterations ahead. In addition, it will be necessary to return to this assessment, because the backlog is constantly updated, priorities change.
So why are story points, not days?
Firstly, at this stage not much is known about the requirements to carry out accurate planning.
Secondly, programmers will not want to evaluate such requirements over time, because then you will remember them ... It is easier for them to answer the question “Is this so big?” than "how much will it take?"
Thirdly, in our case, the team is not familiar with the technology (Sharepoint has just left), and it is simply impossible to give accurate estimates.
What is the use of it?
First, a product owner can reassess its priorities. Since the story A “costs” 13 points, and B is just 2 - let's make it soon.
Secondly, it helps planning. If we know that in the first sprint we made 50 story points, in the second - 55, then in the third we’ll probably do 55 as well
. Thirdly, it's easier. “A” is more difficult than “B”, therefore 21.
And what next? Where are the normal numbers?
Ordinary man-hours start later.
The first sprint is the most difficult, especially with us, with a new team, new technology and a new methodology. Together with the product owner, we identified 9 stories for the first iteration.
For an accurate assessment, we sat down with the most experienced programmer, and given the lack of experience with the rest, we evaluated. In a normal way, and here it was necessary to play poker, but the situation is not the same.
To get accurate grades, each story needs to be broken down into tasks. Each task should be no more than 8 hours, so that in a day it would be clear whether it was done or not. We divided our stories into 2-10 tasks, about such as “Build a UI for the page of trainers”, “Prepare a list of trainers”, etc. We rated each in hours, and it turned out ... What do we need 3 times more time! Had to reduce the backlog of iteration.
As a result, we got that in the first iteration we can finish 67 story points. This is 105 hours of work. That is, now the speed of our team is 67 story points per iteration. As the team becomes familiar with the new technology, speed will increase, and in the next sprint we will be able to develop more story points. Using the estimate in hours, this would not be possible, or it would be necessary to invent some formulas, such as there, “in each subsequent iteration we plan 10% more than in the past.”