#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.   
Spoiler:

 

The Business Analyst meets with the Clients to discuss the project idea, either helping them to further develop it or quickly going over the ready-made documents (if any).   
After this, the BA talks to his/her company's management to determine whether the project should be taken on. It is common for companies to reject projects due to low profitability, lack of resources, excessive bureaucracy, and the client's demands.

It is also possible for them to reject due to the lack of interest. For instance, the project might require to use legacy tech. stack. Another reason might be that the project doesn't fit their portfolio. Maybe they are specialized in developing banking apps and payment systems, but the customer wants to build up a showcase webpage for the toy market.

Now, let's assume that the BA has taken the requirements, discussed those with his company management, and the company has agreed to take on the project.

The BA now begins to compile the PRD (Product Requirements Document) (or SRS - Systems Requirements Specification), which outlines what the contracting company needs to develop for the customer. This document may have different names in different companies, but its essence remains the same.

As we know, Agile does not assume that documentation has to be perfect or comprehensive right away; the level of detail required in describing the functionality of a particular project is decided on a case-by-case basis, usually after talking with the customer.

Usually, the document is prepared in several iterations: certain details are gradually refined to prevent any discrepancies on key points. If something is not done correctly at this stage, it could affect the amount of work the company is required to undertake. In some cases, errors in the PRD may cost the implementing company a great deal of money, not to mention legal costs.

Once the PRD has been written, it is shared with the customer to get their confirmation. Once done, the contract is signed-off.

The BA creates epics that are then added to the Product Backlog. We have already discussed what an epic is, so I will add a few extra details here. These epics are broken down into components so that they can contain all the points from the PRD.

Once all the epics have been created and stored in the Backlog, they should take the place of the PRD. Ideally, the team would no longer need to look at the PRD.

The BA and the Product Owner may decide to prioritize epics if there are many of them, especially if the client adds new requirements (which are usually included in the contract for Agile projects). This is necessary since resources are scarce, and the team may not be able to do everything at once. Therefore, the PO and the BA have to figure out how to prioritize, and one of the most efficient techniques for doing this is the MoSCoW analysis.

MoSCoW is an abbreviation in which M = Must (mandatory to be implemented), S = Should (required, but not vital), C = Could (preferred, but not required anytime soon), W = Won't (not necessary).

Each epic is evaluated and assigned a letter, which determines its priority. Usually, "M" indicates 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" says that the epic may stay in Backlog as just an interesting idea to which you may or may not return someday.

So we assume that based on analysis by the BA and PO, the EPICs have been prioritized, and the main priorities for the development team are now clear.

At this stage, the PO, together with the PM and, rarely, Teamlead, write User Stories for EPICs. Usually, the Stories for some of the highest-priority epics are compiled at the start of a project so the team can begin with a few iterations.

The rest of the EPICs are broken down into Stories slowly over time as the PM, and PO find the time. The team should always have enough work lined up for some iterations, but the moment of making the next Story should be delayed as much as possible since there might be changes that require revising the Story.

If a Story is changed multiple times, it can become confusing. We will discuss how to write Stories in the next article, so I will not go into details for now.

After the Stories are created, the team may decide to evaluate their relative "weight" to calculate the team's Velocity (development team pace).

The reason for evaluating the "weight" of Stories is so that the management team could have at least a rough assumption about the team development pace, so they could plan things ahead.

Because each User Story is unique (even within a single project), we can not have an average estimate of how long the X or Y story will take to implement. Still, some smart people have come up with an evaluation mechanism that might help.

Planning Poker is the most popular method for evaluating User Stories. In this method, team members are given seven cards with Fibonacci numbers on them: 1-2-3-5-8-13-21. The Product Manager (PM) reads out the task, and the team asks questions to ensure they all comprehend it. After all, questions have been answered the PM will ask the team to evaluate the task.

Each team member must decide the complexity of the task for him/herself and choose one of the seven cards to put face down on the table (so the number isn't visible). The simplest task is estimated at 1, and the most difficult at 21. The evaluation unit is called a Story Point (SP), which is to assess the complexity of the task, not how long it will take to implement.

When selecting the card, it is essential that a participant does not reveal their choice, as it can influence the choices of the rest of the team. Upon everyone making their selection, the team flips the cards, and the scores are revealed. This enables the comparison of different interpretations of the complexity of the Story.

For instance, if the majority of participants rated the problem as 5 or 8 SPs, and one participant rated it at 21 SP, then they s/he didn't understand the requirements. Usually, during the initial discussions, the Teamlead inquires whether the participants understand the task, and the team comes to a consensus.

Essentially, everyone agrees on the same Fibonacci number when evaluating the Story, so the number of Story Points to assign is clear.   
If 3 participants rated the Story at 8 SP, and two were assigned a rating of 5 SP, the Teamlead then decides which score to apply.

Frequently, if the team is new, a few repetitions of this evaluation ritual are needed to give the members the opportunity to "sense" the magnitude of an assignment based on the experiences of analyzed and concluded tasks from before.

This ritual may take place on a weekly basis, depending on how quickly the PM and PO develop the Stories. As always, the team should agree on the most suitable time to do this.

Getting back to velocity and its calculation.   
To calculate Velocity, the PM evaluates how many Story Points the team can complete in one sprint. For example, if in the last three Sprints, the team achieved 35, 40, and 38 Story Points, respectively, it can be assumed that the team will reach at least 35 Story Points in the next iteration.

The velocity calculation enables the Teamlead to estimate how many Stories the team can complete in the next Sprint and thus manage the workload.

At the Sprint Planning Meeting, the Teamlead will then examine the top of the Backlog list - containing previously evaluated Story Points and Stories prioritized by the PO and PM - and select tasks whose total weight amounts to, say, 40 Story Points.

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 that 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 the team's Velocity is 29, and s/he wants one of the Stories estimated at 21 SP to be completed soon, then s/he will simply move it to the very top of Backlog and wait for the next Sprint Planning.

An example of rated Stories and Tasks:

 

Assuming the last 4 Sprints have yielded a total of 24, 24, 27, and 25 Story Points (SPs), the Product Owner (PO) has adjusted the task priorities accordingly, making sure to include the Story, "Add system chat in the portal," in the next Sprint.

Additionally, the PO's legal department has asked him to update the website's End User License Agreement (EULA). Taking this request into account, the PO has revised the Backlog as follows:

 

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 have more or less control over the development pace, and let you manage at least some plans, rather than relying on chance.

If the team uses Planning Poker, then the priorities for the next bunch of tasks become straightforward.   
Essentially, the manager will have to pull a few tasks from the top of the Backlog and move them to the Sprint Backlog while making sure that the total SP value of the tasks does not exceed the team's Velocity by more than 5-10%.

After the Sprint is complete, the team conducts a Demo for the customer and then starts an in-house ritual called "Retrospective Analysis" (commonly referred to as "Retro" or "Retrospective").

During this meeting, the Teamlead and/or PM can evaluate the individual contribution of each team member to the recent Sprint. They also point out the main challenges the team experienced and double-check the accuracy of the SP evaluation of the user stories.

The data collected during the Retrospective should be recorded as a protocol (Meeting Minutes) and later used in "lessons learned" sessions. These sessions, which usually happen up to several times a year, briefly look over all the issues that have happened with teams in past projects.

In short, this is a kind of general retrospective analysis of all the summaries of conducted retrospective analysis (sounds odd, but it is close to the truth).

In the image I showed at the beginning of this article, you can observe the connections between the project participants and the steps we discussed. Since there is no need to pull team members away from their work environment by having them attend every ritual and every meeting, the PM selects the minimum amount of participants while making sure this way of doing things will not affect the quality of the decisions.

Giving due consideration to the time of project participants is a quality all good PMs possess.

In this article, we have looked into what the work of the project participants within the project itself looks like, the meetings that are held, and the factors that are taken into account at each sprint.

We have seen that Steps 1 and 2 are only required at the beginning of the project, while Steps 3 to 8 will be repeated every iteration until the project is complete.

Our next article will be about how to write User Stories.