Software Development Life Cycle (SDLC). Scrum Model Step by Step


Scrum framework allows you to implement Agile development methodology. Unlike the waterfall software development life cycle, the distinctive feature of Scrum is the iterative process of developing.

Development divides into several phases. Each of them results into a ready-to-use product. At the end of each step (called sprint in Scrum terminology) a ready product is delivered to a customer. Customer’s feedback helps reveal possible problems or change the initial plan, if needed. If you want your project to strictly follow the main principles of Agile manifesto , you can use Scrum and be sure that you’re on the right path.

Before we continue with Scrum, we should talk about the core roles involved into the process:

  • Product owner. He takes care of the end user’s interests.
  • Scrum master should coordinate the whole process. His another task is to make sure that Scrum is used in a proper way. He also holds the Scrum meetings.
  • Scrum team. Develops the product. Its main tasks are programming, analysis, testing, etc.

Here’s the main steps of development process that Scrum consists of.

Phases of Scrum Model

Step 1. Product Backlog Creation

Product backlog is a list that consists of features that should be implemented during the development process. It’s ordered by priority and its every item is called a User story. Every user story gets a unique ID. This list below shows how these stories can look like. These are actual product requirements that were implemented during the XB Staff Manager Software developing process:

IDUser Story
a-001As a manager, I want to have the possibility to add, delete and edit tasks to manage the employees’ workload
a-002As a manager, I want to have the ability to add new tasks and change the duration and starting date of the current ones using drag-and-drop
a-003As a manager, I want to assign two types of tasks to employees:
-Part-time task
-Full-time task

The description of every user story should include the following required fields:

  • Importance of a user story. It’s acceptable to use any number you want
  • Initial estimate describes the overall capacity of work. It’s measured in story points
  • How to demo. Describes the way of how the working product will be demonstrated

Besides these required fields, the optional ones can be added in case of need:

  • Track  is using to select all user stories of a certain type to change their priority. Can be used it to increase the priority of user stories that relate to the Control panel, for example.
  • Components make up a list of components that will be changed during the work. For example, an application’s modules, such as authentication or search.
  • Requestor is a customer who’s interested in implementing some particular functionality.
  • Bug tracking ID contains a list of detected bugs that relate to a proper user story.

After the product backlog creation is finished you can move to the next step – sprint planning.

Step 2. Sprint Planning and Sprint Backlog Creation

Firstly, you should determine what your sprint’s duration will be. A short sprint allows you to release the working version of a product more frequently. As a result, customer’s feedback will be received more often and all the possible bugs and errors will be revealed in time.

As an alternative, you can prefer a longer sprint duration. It will allow developers to work more thoroughly. The optimal sprint duration is defined as an average of these two options. As a rule, a sprint lasts about 2 weeks. What’s more important at this phase is the cooperation between stakeholders and team members. The product owner  determines the importance of a proper user story, while the scrum team defines the appropriate labor costs.

After that, the scrum team can select the most important user stories from the product backlog. Then team members should decide how they will solve this or that task. The Sprint backlog should be created next. It consists of user stories that will be completed during the current sprint. The amount of these stories depends on their duration in story points assigned to each story during evaluation stage. The team should be capable to finish all these stories on time.

Step 3. Working on the Sprint. Scrum Meetings

After actual user stories for the current phase are chosen, the website development process begins.

To track the current working process, a task board is commonly used. There are usually big cards with the names of particular user stories and a bundle of little sticky notes with description of single tasks which are needed for implementation of this or that story.

These cards are arranged according to their importance. When work on a task has been started, the corresponding sticker is moved from the “To do” field to the “In progress” one. When work is completed, sticker can be moved to the “Testing” field and after the task is successfully tested, the sticker goes to the “Done” field. An example of how the scrum task board can look like is shown below:


There is also a possibility to use specialized software for this task.

For example, Atlassian JIRA (

Other important scrum feature is everyday Scrum meetings. These meetings’ main goal is to get full and veracious information about the current project status. During these meetings every single team member should tell about the task that he has finished, which task he will choose next and what problems he faced during his work.

Moreover, a burn down chart is what the scrum team gets as a result of scrum meeting. It shows you how many tasks remains uncompleted. This chart gives an ability to control the development process and should be updated after every meeting.

The X-axis represents the remaining days of work, while the Y-axis displays the overall amount of story points for the current stage. After a task that required a certain number of story points to complete is over, you can add a point on the diagram to indicate the current progress.

JIRA allows you to create these charts as well:

burndown chart

This chart helps draw conclusions about the current speed of work. Depending on these conclusions, the amount of user stories for the next sprint can be changed.

Day by day meetings help increase flexibility of the development process. They also allow understanding what changes should be made.

Step 4. Testing and Product Demonstration

Since the ideal result of every sprint is a working product, the full life-cycle testing process is very important. There are different ways to minimize costs of the testing period. For example, you can decrease the overall amount of user stories. As a result, the number of possible bugs will be minimized. The other way is to include QA engineers into the scrum team.

The result of every sprint is product demonstration. The Scrum team creates a review and demonstrates the results of their work. On this basis the stakeholders take a decision about further project changes.

Step 5. Retrospective and Next Sprint Planning

Retrospective’s main aim is to discuss the results and determine the ways how to improve development process on the next step. The team should conclude what went well during the working process and what can be done better during the future iteration. When the ways of improvement are defined, the team can concentrate on the next sprint planning.


The main distinctive features of Scrum are agility and continuous progress. It’s provided mostly by permanent communication and close cooperation between the stakeholders at each step. At the phase of sprint planning the product owner communicates with the scrum team. They define how they can divide the existing user stories into several tasks.

During the regular scrum meetings the team members discuss the implementation of each particular task and the ways of solving possible problems. When the sprint is finished, the customer can evaluate the working product functionality at the current iteration. There is a possibility for him to arrive at a decision about further improvements or change the initial project’s paradigm. Finally, all information received during these steps can be used to improve the next sprint results, which helps optimize the development process in the best possible way.


give us a like
The following two tabs change content below.
Dmitry Gurendo

Dmitry Gurendo

XB Software business analyst, PM and dedicated Agile Evangelist. Passionate about assisting and growing efficient teams to deliver products for a better world.