#7. Project approval and further workflow
Now that we know what SCRUM is, it's time to go through all the stages of the project, so that we have a complete picture of what is happening and in what order.
Let's call this picture a wonder-picture for ease of reference.
Step 1: Analyzing the Requirements
It all starts with the Business Analyst (BA) meeting with the stakeholders (we'll call them Clients from here on) to discuss the project idea. Depending on the state of the idea, s/he either helps the client to develop the idea further so that it can become a full-fledged, promising project or, if the idea is already documented and doesn't need further modifications, quickly passes through the documents to understand the main difficulties and risks of the project. Having discussed all the issues with the client, the BA then discusses the project with his company's management in order to decide whether or not to take on the project. Often, companies abandon projects. The most common reasons are low profitability, lack of resources (free programmers with the right skills to develop a project), excessive client bureaucracy (banks, legal and government structures), excessive client demands (slowness, excessive micro-management) and many others. On the other hand, there are cases where the company does not take on the project simply because it is too boring. For example, the company may strive to use new technologies to develop the skills of its teams, and along comes a customer who wants to develop something in an outdated or obsolete programming language. Another reason for turning down the job could be the subject matter of the project itself. For example, if the company is constantly developing payment systems for large customers and popular brands, then the opportunity to develop an online store for children's toys may be unappealing since it doesn't fit the company portfolio. This, by the way, is an example of rejecting a project based on the company's philosophy.
But in our case, let's assume that the BA has taken instructions from the client, discussed the client's requirements with his management, and the company has agreed to take on the project.
Step 2: Development of Primary Documentation
The BA now begins compiling the SRS (Systems Requirements Specification) document, which outlines what the contracting company is going to develop for the customer. I believe that in some companies, this document has another name, but that does not change its essence. As we already know, Agile does not assume that documentation has to be perfect or comprehensive upfront; the amount of detail required in describing the functionality of a future project is determined individually for each project, usually after consultation with the customer.
Often, a document is compiled in several iterations: some details are gradually refined, to avoid ambiguities in key points. If at this stage, the BA makes a mistake, it could affect the amount of work that the company is be required to undertake. In some cases, errors in an SRS may cost the implementing company a fortune, not to mention legal fees.
Once the document has been drawn up, it is agreed with the client and added to the contract, which is signed by both parties (the client and the implementing company).
Step 3: Making Epics
The BA creates epics that are put into the Product Backlog. We have already seen what an epic is, so I'll add only a couple of details here.
Epics are divided into parts in such a way that enables them to conveniently contain all the points of the SRS. Ultimately, once all the epics have been created and put into Backlog, they should completely replace the SRS. Ideally, the team never opens the SRS again and even forgets all about it.
Step 4: Prioritize the Epics
If there are a lot of epics, and particularly if the client adds new requirements (provided this is foreseen in the contract, as would normally be the case for Agile projects), the BA and the Product Owner (PO) may decide to prioritize them. The reasons for prioritizing epics are simple: resources are limited, and the team cannot do everything at once, so the issue of how to prioritize is discussed between the PO and the BA. One of the simplest and most convenient prioritization techniques is the MoSCoW analysis (nothing to do with the Kremlin).
MoSCoW is an abbreviation in which M = Must (definitely required), S = Should (probably required), C = Could (preferred, but not necessary), W = Won't (not necessary). Each epic is evaluated and assigned a letter, which determines its priority. Usually, "M" denotes those epics, without which the project does not make sense; "S": those that you would like to have, but without which the project can live in its early stages; "C" indicates that it would be quite nice to have the epic, but it may well remain in Backlog until more priority things have been dealt with; "W" suggests that the epic may languish in Backlog as just an interesting idea, to which you may or may not return someday.
By the way, like other tools, you can, of course, apply MoSCoW analysis to any project, even those not related to IT at all ☺.
In conclusion, based on analysis by the BA and PO, the epics have been prioritized, and the main priorities for the development team are now clear.
Step 5: User Stories
At this stage, the PO, together with the PM and, in rare cases, Teamlead, make up User Stories for the epics. Usually, at the start of a project, Stories are compiled for several of the highest priority epics so that the team has something to work on for the first few iterations. The rest of the epics are broken down into stories gradually, as and when the PM and PO find the time. The team must always have enough work lined up for several iterations, but the moment of creating the next Story should be delayed as much as possible, as often there are some changes that entail revising the Stories. The problem is, if you change a Story several times, it risks becoming incomprehensible. We'll talk about how to write Stories in the next article, so I'll omit the details for now.
Step 6: Evaluating User Stories and explanation of Velocity
After the Stories are created, the team may decide to evaluate their relative "weight" to calculate the team's "Velocity."
The reason for evaluating the "weight" of Stories is so that we can work out how many of them will be completed in the next few Sprints. And we need to have methods for evaluating Stories, because almost all Stories are unique, even within a single project, and no programmer, however, experienced, can know exactly how long it will take to implement a Story.
So, let's see how the evaluation works.
There are different methods for evaluating Stories, but the most popular of them is Planning Poker. The essence of the method is that each of the developers in the team is given 7 cards with the following Fibonacci numbers on them: 1-2-3-5-8-13-21. The PM then reads out the task (Story), which describes what needs to be developed, and the team asks questions to make sure they have fully understood what's involved in the task. When all the questions have been answered, the PM asks the team to proceed to the evaluation of the task. This requires each participant to decide how difficult this task would be for him personally, and accordingly, he chooses one of the 7 cards and put it face down on the table (so that the number is not visible). The simplest task is estimated at 1 and the most difficult at 21. Note that the participants are asked to evaluate the complexity of the task, and not how long it will take to implement. Each evaluation unit is called a Story Point (SP).
It is essential that when selecting the card, a participant does not reveal his choice, since this may affect the ratings chosen by the other participants. After everyone has made their choice, the team turns over the cards, and the scores are revealed. The beauty of this method is that it allows you to compare different interpretations of the complexity of the Story. For example, if the majority of participants rated the problem as 5 or 8 SPs, and one participant rated it at 21 SP, then he probably misunderstands the requirements. Usually, during the initial discussions, the Teamlead asks the participants whether they understood the task, and the team reaches a consensus. In essence, all agree on the same Fibonacci number when evaluating the Story, so the number of Story Points to assign to it is clear. If 3 participants rated the Story at 8 SP, and two assigned a rating of 5 SP, then the Teamlead decides which score to apply.
Often, if a team is new, several iterations of the assessment are needed so that participants learn to "feel" the weight of the task according to its type, based on the experience of previously evaluated and completed tasks.
The Ritual of evaluating Stories can be done on a weekly basis, depending on how fast the PM and PO develop the Stories. As always, the team should agree on the most convenient time to do this.
So then, how do we calculate the Velocity? This is possible after several iterations have passed, and the team has now able to evaluate the Stories reliably. Velocity is the team's working speed, and it's up to the PM to calculate it. To spell it out, Velocity is the number of Story Points that a team can complete in one iteration. For example, if, during the last three Sprints, a team has completed 35, 40, and 38 SPs' worth of Stories, then the PM may assume that in the next iteration, the team will do no less than 35 SPs' worth of Stories. And so, for the Teamlead, the Velocity calculation enables him to estimate how many Stories the team will manage to perform in the next Sprint, thereby supervising the workload. Accordingly, at the Sprint Planning Meeting, the Teamlead will simply inspect the top of the Backlog list (which consists of previously evaluated Stories' Story Points, with the Stories listed in the priority agreed by the PO and PM) and select only those tasks whose total weight adds up to – say – no more than 40 SP.
For the PM, Velocity gives an understanding of the team's pace – it allows him to measure the "pulse" – and for the PO it is a tool which enables him to prioritize the Stories in Backlog in such a way as to control which Stories the team will add to the next Sprint. If, for example, the PO knows that team's Velocity is 29, and he wants one of the Stories estimated at 21 SP to be completed soon, then he will simply move it to the very top of Backlog and wait for the next Sprint Planning.
Below is an example of rated Stories and Tasks:
Let's suppose that over the last 4 Sprints the team completed work equivalent to 24, 24, 27 & 25 SPs, respectively. Armed with this information, the PO has distributed the task priorities so that Chat Development's Story ("Add system chat in the portal") neatly falls into the next Sprint. The PO's legal department also asked him to update the license agreement on the website ("EULA" - see below) to avoid legal problems. The PO has taken this wish into account, and the prioritized Backlog now looks like this:
Result: the PO can be confident that in the next Sprint which, let's say, should start on February 4th and end on the 18th, the system chat feature will be implemented and the license agreement updated.
As we can see, StoryPoint gives you the opportunity to more or less control the pace and sequence of development and not rely on chance.
Step 7: Backlog Compilation
If the team uses the Story Point method of assessment, then the choice of which tasks to put in Backlog for the next Sprint is simple. In essence, you just need to drag several tasks from the top of the Backlog and put them in Sprint Backlog so that the combined SP value of the tasks does not exceed the team's Velocity by more than 5-10%.
Step 8: Retrospective Analysis
As soon as the Sprint is over, the team conducts a Demo (assuming there is such an arrangement with the client) and proceeds to Retrospective Analysis (often simply called "Retro" or "Retrospective"). You'll recall we briefly described this Scrum ritual in the last article. Now we'd like to mention that besides, at this meeting, the Teamlead and/or PM can also analyze the contribution of each participant to the last Sprint, spell out the main problems the team faced, and double-check the accuracy of the SP evaluation of the user stories. Ideally, info gathered during the Retrospective should be written up as a protocol (Meeting Minutes), for future use in a "lessons learned" session. These sessions, which usually take place up to several times a year, briefly review all the problems and oddities that have occurred with teams in past projects. In essence, this is a kind of Retrospective analysis (sounds odd, but it's close to the truth).
In our wonder-picture, which I posted at the beginning of the article, you can see the links between the project participants and the steps we talked about. As there's no point in unnecessarily pulling team members away from their workplace by dragging them to every ritual and every meeting, the PM selects the minimum number of participants, while ensuring that this approach does not impact on the quality of the decisions.
Respecting project participants' valuable time is an important characteristic of a good PMs.
So, in this article, we have learned how the work of the project participants within the project itself looks like, what meetings are held, and what issues are taken into account at each iteration stage.
Steps 1 and 2 are needed only at the beginning of the project.
Steps 3 through 8 will be repeated every iteration until our team completes the project.
The next article will be entirely devoted to the question of how to write User Stories.