Get started with SCRUM by following these steps

1. Define your first Scrum Team

2. Define your Sprint length
3. Appoint a Scrum Master
4. Appoint the Product Owner
5. Create the Initial Product Backlog
6. Plan and Start your First Sprint
7. Close the Current and Start the Next Sprint

1. Define your first Scrum Team

The team is comprised of of 5-9 members. These members all have a combination of
competencies and can include developers, testers, support, designers, business analysis, etc. All
the members continuously work closely together. The team itself is in charge of delivering
shippable product increments by the end of each sprint.

2. Define your Sprint length

A sprint is a time-box that lasts between 7 and 30 days, and typically it remains the same length
for the duration of a project. A sprint planning meeting proceeds each sprint where the work for
the sprint is planned, and the team commits to completing this work. At the end of a sprint a
review/meeting with a demonstration of the completed work is held. Here the improvements are
reviewed and work for the next sprint is planned. If you don't have a clue of how long the time-
box should be start with 2 weeks.

3. Appoint a Scrum Master

The Scrum Master is the catalyst of the scrum group. They ensure that the scrum group is
effective and progressive. In the event of any impediment, the Scrum Master follows up and
coordinate for resolution of the issues for the group.

You can think of this as the Project Manager for the team, except the person shouldn't dictate
what the team works on and shouldn't overly try to micro-manage anything.

4. Appoint the Product Owner

The Product Owner should be a person that can be in charge of making sure the team produces
value from the project to the business, client or whoever wants the project (the end buyer). The
Product Owner typically writes the client-centric requirements in the form of stories, prioritizes
them, and provides them to the backlog.

5. Create the Initial Product Backlog

The Product backlog is a wish list of all of the user stories (requirements) that is expected to be
completed in the project. The most important story should be in the top of the list, so the entire
backlog is continuously ranked in order based on story importance.

A backlog will typically contain 2 types of work items:

1. Epics - High level stories that are very roughly sketched out without much detail.
2. Stories - More detailed requirements for what should be done (be possible to do). An
epic can typically be broken down into several stories.

A story will typically again be broken down into discrete tasks that the team can work and report
time on. A story can in many cases have a type, such as development, bug/defect, chore, etc.
New stories can be written and added to the product backlog at any time and by anyone.

As you go further down the backlog the items will typically be more rough with less details. As a
story/epic rises in priority more details should be put on it so the team can start working on it.

The Product Owner is free to re-prioritize the backlog as he/she sees fit, at any point in time.

6. Plan and Start your First Sprint

Based on the backlog prioritization, the team now picks items from the list (typically from the
top). The team brainstorms and decides on what and how much they can complete in the
upcoming sprint. This is called the sprint planning meeting.

To run a successful sprint, you’ll need to know how to organize work and plan activities that can
be finished in a short period of time. The purpose of a sprint planning meeting is to identify the
sprint goal and sprint backlog.

• Sprint Goal: This refers to what can be delivered during the sprint.
• Sprint Backlog: The list of tasks to be completed during the sprint to achieve that goal.

Healthy backlog carries out three things:

• Prioritizes each work item, with the most important work listed at the top
• Includes fully-formed user stories the development team can begin to execute on
• Contains an up-to-date estimate for each work item.

Once the team agrees, the sprint is started and the team starts working on the stories.

7. Close the Current and Start the Next Sprint

When the end of the time-box is reached, the end of the current sprint, all planned work should
hopefully be done. If this is not the case it's up to the team to decide if the remaining work
should transfer to the next sprint or be put back into the backlog.

The team now does a retrospective where they discuss what went well and what could be
improved for the next sprint. After that, the sprint planning meeting for the next sprint starts and
the process is repeated.

There's no limit for the amount of sprints, except if they are set by a deadline (based on budget or
time), or the entire backlog is completed. If none of these criteria are met, the sprints just keep
going indefinitely.

Different Roles In SCRUM

The Product Owner:

• Owns the backlog & clarifies the details of the product backlog
• Manage the Project’s ROI and risk
• Build business cases for projects and features
• Be cognizant of the risks
• Take inputs from all stakeholders about what the team should do and translate that into a
“backlog”
• Assign “priority” to items in the backlog
• Determine the “release plan” with help of the team
• Communicate the plan and roadmap with the external stakeholders
 • Participate in the important Scrum meetings
➢ Release and sprint planning
➢ Sprint review
• Be “available” to the team for:
➢ Clarifying requirements
➢ Answering questions
➢ Providing feedback

The Scrum Master:

• Facilitates the team meeting

• Scrum Master is a critical role in the methodology
• The Scrum Master helps the team achieve its goals by doing the following:
➢ Serving the team
➢ Protecting the team
• line manager (one with reporting authority) ideally should NOT become the Scrum
master

What the Scrum Master Should NOT Do

• Manage the team

• Direct the team members
• Assign tasks
• “Drive” the team
• Make decisions on behalf of the team
• Over-rule the team members
• Direct product strategy

The Team:

• Each member of the team is called a “Developer” Because they all contribute to the
development of the product
• The team is SMALL (ideally 7 + or – 2)
• The team is cross-functional Should contain all skills necessary to deliver value to the
customer
• The team is self-managing
• Team members defines the work and effort
• Team members will need to “collaborate” a lot more. Hence look for people who are good at
communication skills and team working
• You need some specialists but more generalists; e.g., testers who can code
• You need a team that will make decisions and take responsibility for them Promoting the right
attitude
• Make it “safe” for people to make mistakes