SCRUM Process Tutorial

What is Scrum?

Scrum is a subset of Agile and one of the most popular process frameworks for implementing Agile. It is an iterative and incremental software development model used to manage complex software and product development. Fixed-length iterations, called sprints lasting one to two weeks long. At the end of each sprint, stakeholders and team members meet to plan next steps. It consists of three roles Scrum Master, Product owner and Scrum team.

Scrum follows a set of roles, responsibilities, and meetings that never change. For example, Scrum calls for four ceremonies that provide structure to each sprint: sprint planning, daily stand-up, sprint demo, and sprint retrospective. During each sprint, the team will use visual artifacts like task boards or burndown charts to show progress and receive incremental feedback.

Understanding the Value of Scrum Project Management

SCRUM is a process in agile methodology which is a combination of Iterative model and incremental model.

One of the major handicaps of the traditional waterfall model was that – until first phase is complete, the application does not move to the other phase. And if by chance there are some changes in the later stage of the cycle, it becomes very challenging to implement those changes, as it would involve revisiting the earlier phases and redoing the changes.

Some of the key characteristics of SCRUM include:

• Self-organized and focused team
• Cross functional team works together as a single unit.
• Close communication with the user representative to understand the features.
• Has definite time line of max 1 month.
• Instead of doing the entire “thing” at a time, Scrum does a little of everything at a given interval
• Resources capability and availability are considered before committing anything.

 Activities in Scrum Project Management

The main activity in Scrum project management is the Sprint, a time boxed iteration that usually lasts between 1-4 weeks, with the most common sprint length being 2 weeks.

• Sprint Planning Meeting: at the start of each sprint a planning meeting is held to discuss the work that is to be done. The product owner and the team meet to discuss the highest-priority items on the product backlog. Team members figure out how many items they can commit to and then create a sprint backlog, which is a list of the tasks to complete during the sprint.
• Daily scrum or daily stand-up: each day during the sprint team members share what they worked on the prior day, will work on today, and identify any impediments. Daily scrums serve to synchronize the work of team members as they discuss the work of the sprint. These meetings are time boxed to no more than 15 minutes.
• Sprint Review: at the end of a sprint the team demonstrates the functionality added during the sprint. The goal of this meeting is to get feedback from the product owner and any users or other stakeholders who have been invited to the review.
• Sprint Retrospective: at the end of each sprint the team participates in a retrospective meeting to reflect on the sprint that is ending and identify opportunities to improve in the new sprint.

 Artifacts in Scrum Project Management

Scrum Project Management requires very few artifacts, concentrating instead on delivering software that produces business value. The main artifacts in Scrum are:

• Product Backlog: this is a complete list of the functionality that remains to be added to the product. The product backlog is prioritized by the product owner so that the team always works on the most valuable features first.
• Sprint Backlog: this is a prioritized list of tasks the team needs to complete during the sprint.
• Burndown charts: these are used to show the amount of work remaining in a sprint and provide an effective way to determine at a glance whether a sprint is on schedule to have all planned work finished.

Roles on a Scrum team

There are three main roles involved in Scrum project management:

• Product Owner represents the customer and is responsible for prioritizing the backlog. The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes-

·         Expressing Product Backlog items clearly.

·         Ordering the Product Backlog items to best achieve goals and missions.

·         Optimizing the value of the work the Team performs.

·         Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Team will work on further.

·         Ensuring that the Team understands items in the Product Backlog to the level needed.

• The ScrumMaster is responsible for implementing the Scrum. A ScrumMaster differs from a traditional project manager in many key ways, including that the ScrumMaster does not provide day-to-day direction to the team and does not assign tasks to individuals. Scrum master is responsible for

·         making the process run smoothly

·         removing obstacles that impact productivity

·         organizing and facilitating the critical meetings

• The Team is made up of a cross-functional group of 5-9 members who are responsible for developing the product. Scrum teams are self-organized will all members collectively responsible for getting the work done.

The Scrum Process

Now that basic vocabulary related to Scrum has been defined I will detail the Scrum process step-by-step.

1. Creating a backlog – in this step, the Product Owner and Scrum Team meet in order to discuss the priority and items on the Product Backlog. The Product Owner must be able to form the product vision. The Product Backlog then, is a prioritized list of what is required for the project and is ranked with regard to importance.
2. Once the product manager creates the backlog, then there will be a Sprint Planning Meeting. During the first phase of the meeting, the Product Manager describes to the team the goals of the project and explains the Product Backlog. During the second phase, the Scrum Team will select the items to be completed during the sprint from those with highest priority on the Product Backlog.
3. Once the items to be worked on have been selected, a potential Sprint schedule is constructed – taking into account the availability of the team members to devote their time to the project. The items in the Product Backlog are assigned and broken down into individual tasks. Once this occurs, this document is the Sprint Backlog.
4. The Sprint begins and lasts from 15-30 days. During the Sprint, no other tasks are added to the backlog.
5. Daily Scrum begins when the sprint begins. The Daily Scrum is a 15-minute stand-up meeting where each member of the team gives a very brief report to everyone else – what they accomplished since the last Daily Scrum, what they hope to accomplish, and issues that have come up. Here, the Scrum Master will make note of issues and attempt to resolve them – after the meeting.
6. Sprint Review – once the Sprint ends, everyone gets together in a meeting to share what he or she accomplished during the sprint.
7. The process begins again with a new list of prioritized tasks on the Product Backlog.

How the Process is done? An example!

Having read about the technical jargons of SCRUM; let me try to demonstrate the whole process with an example.

Step #1: Let’s have a SCRUM team of 9 people comprising of 1 product owner, 1 Scrum master, 2 testers, 4 developers and 1 DBA.

Step #2: The Sprint is decided to follow 4 week’s cycle. So we have 1-month Sprint starting 5^th June to 4^th of July.

Step #3: The Product owner has the prioritized list of user stories in the product backlog.

Step #4: The team decides to meet on 4^th June for the “Pre Planning” meeting.

• The product owner takes 1 story from the product backlog, describes it and leaves it to the team to brainstorm on it.
• The entire team discusses and communicates directly to the product owner to have clear understood of the user story.
• In a similar way various other user stories are taken. If possible, team can go ahead and size the stories as well.

After all the discussion, Individual team member go back to their work stations and

• Identify their individual tasks for each story.
• Calculate the exact number of hours on which they will be working. How the member concludes these hours; let’s check that

Total number of working hours = 9
Minus 1 hour for break, minus 1 hour for meetings, minus 1 hour for mails, discussions, troubleshooting etc.
So the actual working hours = 6
Total number of working days during the Sprint = 21 days.
Total number of hours available = 21*6 = 126
The member is on leave for 2 days = 12 hours (This varies for each member, some may take leave and some may not.)
Number of actual hours = 126 – 12 = 114 hours.

This means that the member will actually available for 114 hours for this sprint. So he will break down his individual sprint task in such a way that total of 114 hours is reached.

Step #5: On 5^th of June the entire Scrum team meets for the “Planning Meeting”.

• Final verdict of the user story from the product backlog is done and the story is moved to the Sprint back log.
• For each story, each team member declares their identified tasks, if required can have a discussion on those tasks, can size or resize it (remember the Fibonacci series!!).
• The Scrum master or the team enter their individual tasks along with their hours for each story in a tool.
• After all the stories are completed, Scrum master notes the initial Velocity and formally starts the Sprint.

Step #6: Once the Sprint has started, based on the tasks assigned, each team member starts working on those tasks.

Step #7: The team meets daily for 15 minutes and discusses 3 things:

• What did they do yesterday?
• What they plan to do today
• Any impediments (roadblocks)?

Step #8: The scrum master tracks the progress on daily basis with the help of “Burn down chart”

Step #9: In case of any impediments, the Scrum master follows up to resolve those.

Step #10: On 4^th July, the team meets again for the review meeting. A member demonstrates the implemented user story to the product owner.

Step #11: On 5^th July, Team meets again for the Retrospective, where they discuss

• What went well?
• What did not go well
• Action Items.

Step #12: On 6^th July, Team again meets for the pre-planning meeting for the next sprint and the cycle continues.

Tools that can be used for SCRUM activities:

There are many tools available which can be used extensively for tracking the scrum activities. Some of them include:

• Jira
• XPlanner
• VersionOne
• Sprintometer
• ScrumNinja

Advantages of Scrum

• More transparency and project visibility: With daily stand-up meetings, the whole team knows who is doing what, eliminating many misunderstandings and confusion. Issues are identified in advance, allowing the team to resolve them before they get out of hand.
   
• Increased team accountability: There is no project manager telling the Scrum Team what to do and when. Instead, the team collectively decides what work they can complete in each sprint. They all work together and help each other, improving collaboration and empowering each team member to be independent.
   
• Easy to accommodate changes: With short sprints and constant feedback, it’s easier to cope with and accommodate changes. For example, if the team discovers a new user story during one sprint, they can easily add that feature to the next sprint during the backlog refinement meeting.
   
• Increased cost savings: Constant communication ensures the team is aware of all issues and changes as soon as they arise, helping to lower expenses and increase quality. By coding and testing features in smaller chunks, there is continuous feedback and mistakes can be corrected early on, before they get too expensive to fix.

 Disadvantages of Scrum

• Risk of scope creep: Some Scrum projects can experience scope creep due to a lack of specific end date. With no completion date, stakeholders may be tempted to keep requesting additional functionality.
   
• Team requires experience and commitment: With defined roles and responsibilities, the team needs to be familiar with Scrum principles to succeed. Because there are no defined roles in the Scrum Team (everyone does everything), it requires team members with technical experience. The team also needs to commit to the daily Scrum meetings and to stay on the team for the duration of the project.
   
• The wrong Scrum Master can ruin everything: The Scrum Master is very different from a project manager. The Scrum Master does not have authority over the team; he or she needs to trust the team they are managing and never tell them what to do. If the Scrum Master tries to control the team, the project will fail.
   
• Poorly defined tasks can lead to inaccuracies: Project costs and timelines won’t be accurate if tasks are not well defined. If the initial goals are unclear, planning becomes difficult and sprints can take more time than originally estimated.