Scrum requirements assessment

I will talk about the evaluation of the work in the scrum. It is recommended to perform it twice - first in story points , at the level of user stories , and then in hours , at the level of tasks in the current iteration. I will also try to explain why this is done twice.

In our company, we decided to take the introduction of Agile principles more seriously, and the core ideas - Scrum . I was assigned to implement this business in a small project that should be ready by September, with 4 programmers and a web designer. The task of the project is the migration of the html site to Sharepoint 2010, and the addition of many new features.

Previously, we once thought that the morning Scrum meeting was already such a normal scram. But, after reading a little and digging around, it turned out that in general, not quite.

So, the initial estimate is guesstimate.
')
The initial evaluation of the project is at the level of user stories that are in the Product Backlog. It is recommended to write user stories in a slightly non-graceful, at first sight, manner:
“As [type of user] I want [to perform an action] for [reason]” (As a [type of user] I want [some goal] so that [some reason]).

For example, instead of the usual “A student should be able to choose the desired course” - “As a student, I want to choose the desired course in order to get the necessary knowledge”. On the one hand, it sounds very artificially, but on the other hand, 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. Albeit unusual.

My backlog consists of 40 stories of this level. These are not enough detailed requirements to make accurate estimates, but something can be done - to evaluate the backlog in story points.

What is story points? This is a relative assessment of each story. The theory proposes to use the power of two for the evaluation (2, 4, 8 ...) or the 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, you need to choose the simplest story and evaluate it as 1. In our case, this is the story - “As a user, I want to see information about trainers in order to know their competence.” After that, we choose the most complex story, and evaluate it as a maximum, in our case - 21. This is the story "As a subscriber, I want to order a course so that I can attend it."

After this, the theory proposes to evaluate the remaining requirements, in order of priority. To do this, you can use a planning poker technique, where each programmer writes his or her own assessment of the requirements on the sheet, and then everyone shows at the same time, and the discussion begins if the estimates are very different.

Evaluating the entire backlog is not necessary - it is enough to evaluate only the stories a few iterations forward. In addition, it will be necessary to return to this assessment, because the backlog is constantly updated, priorities are changing.

So why story points, not days?

First, at this stage, not enough is known about the requirements to conduct accurate planning.
Secondly, programmers will not want to evaluate such requirements over time, because then you remember them ... It is easier for them to answer the question “Is it so big?” Than “how long 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, the product owner can revise their priorities. Since history A is “worth” 13 points, and B is only 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 will probably also make some 55.
Thirdly, it is easier. “A” is more complicated than “B”, therefore 21.

What's next? Where are the normal numbers?

Normal man-hours begin later.
The first sprint is the most difficult, especially with us - with a new team, a 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, it was necessary to play poker here, but the situation is different.
To get accurate estimates, each story must be divided into tasks. Each task should be no more than 8 hours for the day to be clear, it was done or not. We have divided our stories into 2-10 tasks, something like “Build a UI for the trainers page”, “Prepare a list of trainers”, etc. We appreciated each in hours, and it turned out ... What do we need 3 times more time! I had to reduce the backlog of the 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, the speed will increase, and in the next sprint we will be able to develop more story points. Using the estimate in hours, it would be impossible, or it would be necessary to invent some formulas, such as there, “in each subsequent iteration we plan 10% more than in the past.”