SCRUM is undoubtedly the most popular Agile software development methodology. Unlike a development approach without a methodology or with what is now called the waterfall system, SCRUM requires a team to develop projects in short stages. Each of these stages should result in delivering a functional part of the whole system to the end-user. This system ensures the flexibility to meet business requirements even if they are constantly changing without sacrificing the delivery of key functionalities.
Of course, there will always be factors which will hinder any project. Even if you are new to SCRUM, you can benefit from a vast pool of past experience because there is no issue that hasn’t been encountered before. There are five SCRUM practices to pay particular attention to when using this methodology:
- The SCRUM Team
- The Backlog
- Estimates
- Monitoring progress
- Quality
The SCRUM Team
Even though SCRUM methodology allows for development teams consisting of as few as three people and as large as nine, the optimum size is around six or seven. This will help ensure you have enough people with the full range of competencies your project requires. In software development, this means architects, developers, testers and business analysts, and everyone has equal responsibility for the project regardless of their role. With the help of the SCRUM Master, team members organize their work together as a team without any outside interference. They are in the best position to know how much time they will need to design and implement functionalities in the Backlog.
Meanwhile, management and other stakeholders should keep an eye on motivation by immediately removing obstacles, supporting an optimal working environment, setting clear goals, and defining a reasonable time frame for the project.
Communication is a very important issue in any development team, and SCRUM Teams are no different. As most of us have recently learned, communication with a remote team comes with extra challenges. This is because many important details and non-verbal cues can be missed during a Skype call or in a Microsoft Teams chat. Good communication practices include:
- Setting and sharing guidelines on how to effectively communicate critical information.
- Requiring team members to report when obstacles arise and when they solve a problem that has affected the work of others.
- Setting up email notifications and integrating teamworking tools with the chosen communication channel so that the team is promptly informed of changes.
- try to keep one team together from project to project whenever and wherever this is possible and reasonable. Once a team has worked together, they will know how to cooperate to get the best results.
The Backlog
Once a team is formed, the first item of business in SCRUM meetings is to create the list of functionalities to be completed. This list, based on user stories, is called a product Backlog. The team is guided in this by management’s preliminary business analysis of the project.
Each item in the Backlog should be carefully defined with a detailed description, its priority level, a point valuation, and formal acceptance criteria. There are a number of different—but not exclusive—techniques for setting the priority levels. For example:
- MoSCoW—an acronym for the expression: “Must haves”, “Should haves”, “Could haves” and “Won’t haves”.
- Business value—the Product Owner helps set priorities based on a forecast of each function’s financial value to the company.
- “Walking skeleton”—this technique is used most often to build MVPs. We set the priority to have a demonstrable, working application framework as soon as possible.
- Technological risk—the riskiest tasks have the highest priority possible. Doing these tasks first significantly reduces the chances that failure will occur in later stages, when so much effort has already been sunk into the project.
Tasks should be prioritized with the project’s objective in mind. As you might imagine, creating a prototype will require a different mindset and Backlog than rewriting a system already in operation.
As each task is prioritized, a team member can also immediately be assigned responsibility for it.
Here is an example Backlog:
If a certain Backlog item is highly valued, consider breaking it down into smaller, related tasks. It is easier to estimate the time needed to complete small tasks than larger ones, and if you do estimate incorrectly, you are likelier to guess too long than too short.
The product Backlog is an important tool for Sprint Planning. Please keep in mind the distinction between the sprint Backlog and the product Backlog. You will use the product Backlog while planning each sprint to create the sprint Backlog. This sprint Backlog is the one that’s etched in stone, as it were. Like the sprint goal, it will not—or at least should not—be changed. In effect, it’s a promise to the various stakeholders that you will create something they can use.
On the other hand, the product Backlog can be updated at any time by a change in priorities (especially due to external factors) or requirements to correct the course of the project.
Evaluating
To begin each sprint, the development team evaluates the items on the Backlog. The Product Owner should participate in this process to extend an invitation. Their business perspective will help prioritize the sprint. When the Product Owner has an understanding of how the team evaluated each functionality, they will be better able to address any concerns whenever you need their input. The process typically runs in the following order:
- Prioritizing
- Identifying what each item will require—time, expertise, tools, and so on
- Discussing with the Product Owner and, if necessary, asking for clarification
- Rating the tasks
Ratings are usually given in a number of points from 1 to 100 and indicate the task’s complexity level. Each member should propose their own value and agree to abide by the final group compromise.
However, you may find that this process is too messy and subjective. If so, you might try the following formula:
Rating = (Optimistic + (4 x most common rating) + Pessimistic)/6
(For a seven-person team, you would multiply the most common rating by 5 and divide everything by 7.)
To illustrate with a seven-person example, imagine that Jenny rated Item D at 75, Emily and
Arturo at 66, Zach at 65, Iqbal at 64, Monique at 54, and Tran at a quite optimistic 38. Your math then looks like this:
(75 + (5 x 66) + 38)/7 = (75 + 330 + 38)/7 = 443/7 ≈ 63
So, Item D is rated at 63.
The next step is to calculate the time value of one point in order to give the project a time frame. This value will depend on the project in question since each item in a Backlog is judged against others in the same Backlog and not against other projects. You might decide that one point equals an hour, four hours, or more. It is good practice to assume that each team member will spend 6½ hours daily on project work, saving the rest of the workday as time for SCRUM elements and mitigating risks.
When you plan your sprint, don’t stretch it out or try to compress the work. SCRUM’s design leads to a rhythm for the team, and keeping that rhythm constant translates into timeliness. You will have a few competing factors in your Sprint Planning. On the one hand, it’s best not to pursue several goals at once and lose focus, tempting you to add time to the end of the sprint. On the other hand, adding some smaller tasks will help maintain your rhythm and ensure that the entire team is consistently productive.
Monitoring progress
Agile methodologies do not require the client to precisely define what is to be delivered and what the acceptance criteria will be—which of course, is the basis of its strength as a flexible project management method. How, then, do we measure the final success of the project? We initially analyze the business objectives and the requirements in the overall system specification. We define and validate the direction of the work we will do, and each sprint we plan gives us the opportunity to delve deeper into each particular functionality. This will give us more detailed documentation as we reach the end of each stage, and key stakeholders will be consistently involved in developing and validating the system from the outset.
Azure DevOps or Jira are particularly useful tools for monitoring progress on a daily basis—if your SCRUM Team consistently keeps it updated. These tools make it easy to report information on active tasks and how much more time it will take to complete them. Other stakeholders, from the Product Owner, through your firm’s management, to the client, get a graphic representation of a task’s progress. Firing charts are the most useful for this:
They tell us how much work remains to be done in a designated sprint or in relation to the total time planned for the project:
These charts let anyone plan and estimate the actual completion date and detect obstacles causing delays in real-time.
The development team has a more immediate method of monitoring progress because of its daily SCRUM meetings. At the same time every day, they meet for 15 minutes to report to each other:
- What was achieved yesterday?
- What will you be working on today?
- Are there any obstacles?
This keeps the entire team up to date on the project’s status and the sprint’s progress.
Finally, do not neglect the Retrospective stage before going on to the next sprint. This very important and often overlooked element of SCRUM is a meeting at the end of each sprint where the team discusses what went well and what elements still need to be worked on. Members make suggestions on how the team cooperates to improve efficiency and quality. Unfortunately, being at the end of the cycle—and possibly late Friday afternoon—means that the team members are either tired or anxious to start the weekend or both, and there’s pressure to close a sprint on time. But skipping the Retrospective is not good practice. Feedback and innovation are important opportunities not just for the project and the company, but for each team member’s professional growth.
Quality
SCRUM methodology goes some way toward ensuring that the software that is delivered is free of errors. Developers and testers work together every day, usually in the same room, so there are plenty of opportunities to check the code along the way—and little room for excuses not to.
However, the end-user is often not able to see the results for the first few sprints.
Since having a demonstrable result at the end of each sprint is beneficial, we can create interactive mock-ups with a UX prototyping tool such as Axure or Figma. This allows us to test the functionality before it is implemented and gather user feedback. They can then make comments, suggest changes, and adapt the subsequent implementation to actual business needs.
But just having the team members in the same space, even using a pipeline, will not by itself prevent errors. The team will need to operate under appropriate policies. One such policy could be to require a peer review of all changes sent to the repository. This reduces logic errors and possible low code quality. Also, strongly consider automated testing and continuous delivery.
These factors ensure that every change is first tested in the system while delivery to the end-user is as quick as possible. Then we have a chance to immediately catch possible errors and verify new functionalities.
Summary
The SCRUM framework has won over many of the world’s project managers using an agile methodology. Given an adequate preliminary analysis, it will work well even—or particularly— when we do not yet have precise business requirements. With proven tools and an experienced SCRUM master, agile software development methodologies offer maximum productivity, fast delivery times and high-quality results.
