Scrum an Agile Framework

Developed by Fridrik Karlsson

Scrum Framwork

The 21st century is becoming more and more dependent on software than ever before, in the 20th century most companies had predefined projects and was therefore more predictable. With predefined projects, the tasks involved in developing or manufacturing the final product could be planned in advance. If the requirements, design, and implementation can be planned in advance and the final goal is in sight, a framework called the waterfall method is suitable. It is a step driven method where each step is planned in advance.

In software development the waterfall method is not as suitable, as the market today calls for more flexibility and responsiveness, hence more unpredictability. The Scrum method is more suitable for projects that are unpredictable, that is the requirements and design of the project is constantly changing. Scrum works on the agile framework, by using iterative and incremental processes in order to cope with the ever changing requirements and customers’ needs.

History

The Godfathers of Scrum

Hirotaka Takeuchi and Ikujiro Nonaka are regarded as the godfathers of Scrum. They realized that companies were moving towards more flexibility and speed in developing new products, at the same time minimizing cost and have high-quality products. Takeuchi and Nonaka described the old approach as a relay race, a team working towards a common goal but not working together at the same time to reach their goals, instead one player ran at a time and when he finished the next one could go. This is much like the waterfall method. Takeuchi and Nonaka introduced a new holistic approach and described it as a rugby team working together to reach a common goal.

Modern Scrum

In the 90´s Jeff Sutherland and Ken Schwaber continued working on the idea from Takeuchi and Nonaka, it later involved into the Scrum method. In 1995, they first presented their method at the OOPSLA conference in the US and published a paper “SCRUM Software Development Process”.

Sutherland and Schwaber developed the Scrum method with software development in mind. Complex software development projects can have a high level of uncertainty and are constantly changing, therefore the traditional step-by-step method did not fit.

In 2001, Sutherland and Schwaber alongside 15 other software developers worked together to come up with the Agile Manifesto. The Agile Manifesto is a set of 12 principles for software development.

Roles

Scrum Roles

In Scrum there are three roles that need to be fulfilled:

• The Product Owner
• The Scrum Master
• The Scrum Development Team

For each role, there is a set of responsibilities, in order for a project to be successful each team member has to fulfill those responsibilities.

The Product Owner

Usually, the Product Owner is a single person whose responsibility is to maximize the return on investment of the project he controls. The Scrum Master and the Development Team are not to be in direct contact with the customer/s, the Product Owner is the one responsible for being in contact with the customer/s to interpret their needs. The Product Owner then creates the Product Backlog which contains the tasks the Development Team needs to fulfill, it is vital that the Product Owner describes and ensures that the Development Team understands what needs to be done. He also prioritizes the tasks in the product backlog and has the final vote on what tasks need to be done and in what time period. Even though the Product Owner decides which tasks are to be taken, he does not manage what work is done within each task that is up to the Development Team and the Scrum Master. Throughout the project the Product Owner is constantly working together with the team and talking to customers, he is responsible for updating the product backlog in case of new requirements, review tasks that are completed decides whether to ship the product and can decide whether to continue development or not.

The Scrum Master

As with the Product Owner, the Scrum Master is usually a single person whose responsibility is to ensure that the team follows the Scrum framework and its practices and rules. Initially, in the planning process, the Scrum Master focuses solely on creating the Product Backlog with the Product Owner and planning Scrum events such as Daily Scrum meetings, Sprint Planning meetings, Sprint Review meetings and Sprint Retrospective meetings. Later on, when the initial plan is complete the Scrum Master often joins the Development Team. The main difference between the Product Owner and the Scrum Master is that the Scrum Master has no authority over the Development Team and does not take decisions that affect the development process. He is rather an advisor/helper and only interferes when the team is not following the principles of the Scrum framework. He is supposed to help the team members when they need additional help, when the team is not working together or if there are technical problems.

The Development Team

After the Product Owner and the Scrum Master have done their work in the planning process, it is up to the Development Team to complete the tasks and come up with a solution that satisfies the requirements set by the Product Owner. The importance of the Scrum framework is that the Development Team is a team, they as a team are responsible if something that goes wrong or if something is done well, not a single individual. The Development Team are cross-functional so they have the knowledge and experience to complete the tasks they are assigned to. Generally, the team consists of 3-9 members, if there are too few, the tasks may not be completed and too many can lead to management issues. As noted before the Product Owner does not hand out detailed work plans regarding each task, the Development Team reviews each task before each sprint and divides it into more tasks and estimates the work time needed for each task. The Development Team is responsible for completing those tasks and hand out a shippable product at the end of each sprint.

• A Sprint is an iterative process where work is split into different periods, from one week up to 30 days at a time. In each Sprint, the team focuses on completing the tasks in that Sprint and make them ready so they can be presented and reviewed.

The Scrum Plan

The Scrum Plan

Sprint Planning

The Scrum team; the Product Owner, Scrum Master, and the Development Team attend the meeting. During the meeting, the Product Owner takes tasks from the Product Backlog and tells the team what tasks are important and are to be included in the future Sprint. In this step, it is vital that the Product Owner can let the team know what needs to be done and that every team member understands the task at hand. But, the Product Owner does not include all the tasks in the Product Backlog, generally, the next two or three Sprints are under consideration. The challenge in Sprint Planning is time management because ideally, they have to be able to complete the tasks selected at the end of the Sprint.

Daily Scrum

Each day there is a Daily Scrum meeting, the meeting is attended by the team. The Scrum framework ideally wants the meetings to be at the same time and at the same location each time and are usually between 5-15 minutes. The meeting can be attended by outside parties, but they are not allowed to pitch in just observe and listen.

There are three questions every team member has to answer:

• "What did you do yesterday?"
• "What will you do today?"
• "Are there any impediments in your way?"

The Scrum Master ensures that all the team members answer these questions, these questions provide an excellent overview of the work that is done and what needs to be done. It provides a certain transparency to the work of each team member.

If any issues or conflicts come up during the meeting, they are handled after the meeting. The meeting is just to see where everyone stands and if they are on schedule.

Sprint Review

At the end of each Sprint, the team showcases what they have done during the Sprint, often called a demo. It is different according to companies who attends the meeting, e.g. only the Scrum team, the Scrum team along with management and other Scrum teams. Ideally, the work that is showcased is supposed to be completed, but this is not always the case and it can be a good way of getting feedback from other Scrum teams or/and customers to further enhance their project. Sprint Review takes place every 2-4 weeks depending on the length of each Sprint.

Sprint Retrospective

The meeting usually takes place after the Sprint Review, the Scrum Master is responsible that the meetings takes place. The team discusses the recently completed Sprint and how the experience gained from it can help in improving future Sprints.

Artifacts

Product Backlog

Product Backlog

The Product Backlog contains a list of items that the Product Owner and the Scrum Master have made after interpreting the customer needs. It is a to-do list of what needs to be done in order to deliver a successful product. The items in the list are prioritized to maximize the return on investment and are only added to the Product Backlog if they add value to the project. The team estimates how long each task will take during the Sprint Review and divide each task into smaller tasks, as the requirements can be changing throughout the project, the list is constantly changing. Whether new items are added or current items are modified. As the Product Backlog changes throughout the project, the level of detail of each task is different. Tasks that are not in the next couple of Sprints have a brief description of what is needed and tasks that are in the next couple of Sprints have a more detailed description. With having lower level of detail in tasks that are not in the current sprint, prevents time-consuming processes in acquiring requirements and needs for that task and the requirements can change over time. The Product Owner is responsible for maintaining and changing the Product Backlog.

Sprint Backlog

Example of a Scrum board

The Sprint Backlog contains a list of items the from the Product Backlog, usually the items with the highest priority end up in the Sprint Backlog. The items in the Sprint Backlog are selected by the team and the team should not select more items than they can handle each Sprint because the team is trying to complete all the tasks in each Sprint. After the team has selected the number of items from the Product Backlog, each item is divided into more tasks and an estimate is made. The estimate is given in story points, story points are used to measure the effort needed to finish a specific task. The story point scale can be different between teams, the scale can be; 1,3,5,8,13,40,11 or xsmall, small, large, xlarge e.g.,paper board Note the story points are not measured in hours. The Sprint Backlog is often represented with a Scrum Board. The Scrum Board provides an overview of all the Product Backlog tasks and the Sprint Backlog tasks within the Sprint. Often the board has 5 columns; The Product Backlog tasks column, a to-do column showing all the Sprint Backlog tasks, an in progress column showing all the Sprint Backlog tasks that are in progress, a test column where completed tasks are waiting to be tested and finally a done column showing the completed Sprint Backlog tasks. The Scrum Board can be in the paperboard that is available in the team room or a digital board on a website, often the team is using both forms.

Planning Poker

To estimate the story points a common method is used called planning poker. As the name implies it builds on the poker principles, every team member gets a set of cards, on each card, there is a story point e.g. there can be 7 cards if the scale is 1,3,5,8,13,40,100. The team goes over each task in the Sprint Backlog and gives an estimate of how many story points that specific task needs. The purpose of the planning poker is that each team member selects a card that only he can see and the team reveals the card they chose at the same time. This ensures that the estimate is not affected by other team members. If a team member has an estimate that is different than the majority, either too low or too high, the team member gets a chance to explain the reason for that estimate. If the team does not agree on the number of story points for a specific task, a discussion takes place until every team member is satisfied with the number of story points. Often the team member assigned to the task has more influence on the estimate than other team members.

Example: A team of 6 is voting on a task, they reveal their cards at the same time. 3 team members have an estimate of 5 story points, 1 has an estimate of 13 story points and the last 2 an estimate of 3 story points. The team member that voted 13 story points gets a chance to explain his estimate. After he explains himself another round of poker is played, voting on the same task with his explanation in mind. The team members all reveal their cards again at the same time. Now 4 team members have an estimate of 8 story points and the other 2 an estimate of 5. As this is has been discussed and the majority of votes are 8 story points, this task gets an estimate of 8 story points.

Increment

“The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.” An Increment must be completed, in usable condition whether the Product Owner wants to release it or not.

Sprint Burndown Chart

Example of a Burndown Chart

Is a chart to monitor progress throughout the Sprint, it displays the progress remaining in the Sprint. The x-axis represents the time of the Sprint (usually in days) and the y-axis represents the work remaining. There is a line on the chart showing the effort remaining and often another line showing the ideal effort of the team. The ideal effort line can help the team see where they stand if they are above the line means that they are behind schedule. This can be because the team did not make an accurate estimate or that the task has changed during the Sprint if there are drastic changes to the Sprint that affects the progress of the Sprint the Product Owner has authority to cancel the Sprint if needed. If the team is ahead of schedule the remaining effort line is under the ideal effort line.

Implementing Scrum

Is Scrum for me?

When implementing Scrum one has to be sure that the Scrum framework fits and can be implemented. Before implementing Scrum a couple of key things have to be in order before implementing the Scrum framework:

• Have a Product Owner and a Scrum Master that are qualified
• Teams are cross-functional, the team has the skill and knowledge to complete the project
• Everyone is willing to follow the rules and principles of the Scrum Framework
• Flexibility is high and responsiveness is key to delivering a successful project
• Requirements are unknown and can change frequently throughout the project
• If the deadline of the project is strict
• If the project is new to the company/team
• Team size is between 3-9

Scrum is not the ideal framework when:

• If someone does not want to follow the Scrum Framework, every member has to be 100% Scrum!
• All processes and requirements are known in advance
• There is low level of complexity
• All aspects of the project can be planned in advance
• The project is not new to the company/team, has been done before
• Teams are not cross-functional, team members have to work on other projects at the same time
• If the deadline of the project is more than a couple of years, Scrum is costly

After going over these points and you have decided that the Scrum Framework is suitable, the first thing to do is assemble the team. Starting with the Product Owner, assigning a Product Owner can be the most vital decision to make because he is the one responsible for maximizing the value of the project and interpret what the customer wants and needs from the product. Next up is the Scrum Master, the Scrum Master must be willing to follow the Scrum Framework at all times and aid the team members and mentor them in the art of Scrum. You do not have to assemble the Development Team in the start, as the project is still in the planning stages and the requirements are not clear. The Development Team has to be ready before the first Sprint and have the knowledge and skill to deliver a successful project. When the Scrum team is assembled, a Sprint planning meeting is held, which takes the most vital Product Backlog tasks and plans the work for the next Sprint. A Scrum board is created to provide an overview of the project along with the Burndown Chart. The tasks in the Sprint are not supposed to be changed, but often times unpredictable events can lead to changes and the team has to be able to react accordingly. By modifying the Sprint or canceling it of needed (the Product Owner is the only one with authority to do so). After the Sprint (usually 2-4 weeks), there is a Sprint review. During the Sprint review, the team demos what work has been done and gets feedback if any. After the Sprint review, the team holds a Sprint retrospective meeting to reflect on what happened during the recently finished Sprint to improve the future Sprints. This process continues in iterations (2-4 weeks) until the project is finished, that is a new Sprint planning meeting is held at the beginning of each Sprint, next, the Sprint is reviewed and a Sprint retrospective meeting is held after the review.

Scrum in projects not concerning software development

There is nothing that says Scrum can not be applied to projects other than for software development, Scrum can be used in all types of projects. But Scrum does not always fit the project even though it can be applied. The Scrum method is time-consuming and costly, with meetings every day and constantly planning and reviewing the work plan. If the project fits the points mentioned before (See Is Scrum For Me?) most likely Scrum can be applied.

Further Reading

If interested in learning more about Scrum, http://www.scrum-institute.org/index.php provides an insight in the Scrum universe and offers free training in the art of Scrum.