Table of Contents

• Introduction
• Scrum Roles
• Organization
• Productivity

Introduction

The best place to learn more is at the Scrum Methodology website. As I learn more about the Scrum Methodology and the Agile Manifesto, I realize I have used Agile Methodology most of my career. When I worked at Tektronix, I worked with some of the early pioneers of this movement and adopted many of the practices they advocated in running the Internal Diagnostics team. Upping the quality of the product and reducing the work overload of the engineers is the goal of any good project lead.

More recently, I went to a Scrum Master course the end of August of 2016 to learn more. The class is taught by Mike Cohn, founder of Mountain Goat Software. This page is based on information I have learned from Mike Cohn directly and in his class as well to what I learned working with Ward Cunningham and Rebecca and Allen Wirfs-Brock at Tektronix. This page only includes the high level information. I also include SCRUM.org for Glossary definitions. To better understand the SCRUM process, I would highly recommend taking Mike Cohn’s class.

Scrum Roles

Scrum is divided into four main groups. Mike gave an example of a race car, I have expanded it a bit to describe all four roles:

1. Project Owner (PO) – SCRUM.org defines it as “the role in Scrum accountable for maximizing the value of a product, primarily by incrementally managing and expressing business and functional expectations for a product to the Development Team(s).” The person who sets the objectives for the team and helps guide the team to the completion of each sprint and project – the race car driver
2. The Team (Team) – The Team usually refers to the Development Team (“the role within a Scrum Team accountable for managing, organizing and doing all development work required to create a releasable Increment of product every Sprint” SCRUM.org). The group of people (usually 5-9, with a maximum of 14) who decide on the specific tasks and do the work each sprint, usually includes (but is not limited to) lead programmer, programmers, testers, technical writers. The term Team, according to can also refer to the larger SCRUM Team, SCRUM.org: “a self-organizing team consisting of a Product Owner, Development Team and Scrum Master.” The teams are self-organizing. If one person is on two teams, that person should be assigned to one of the teams at least 60% of the time. Since the teams are small, each person should be willing to do whatever needs to be done to succeed in completing each Sprint, no matter what their preferred roll is. It is critical that all team members help the team to succeed. – the parts of the race car that must work together for the sprint to succeed.
3. Scrum Master (SM) – Scrum.org defines it as “the role within a Scrum Team accountable for guiding, coaching, teaching and assisting a Scrum Team and its environments in a proper understanding and use of Scrum.” The person who is more concerned on how to complete the Sprint successfully, the provider of the tools and methodology so that the member of the Team can accomplish the tasks that are specified to be completed during the sprint – the mechanic, keeps the race car running smoothly, by providing the guidance, tools, and materials to help each part work at its optimal best.
4. Shareholders (or Stakeholders) – the people who benefit most and have a direct interest in a successful completion of the sprint and overall project – the car owners, get excited each time the car completes a lap (sprint), get paid when the car crosses the finish line.

Terms

The key terms that are needed to be understood to do Scrum well are:

1. [User] Stories – The building blocks of the project, usually written in the form: “As a <type of user>, I <want | can | need | …> so that <reason>”
2. Story-Writing Workshop – These are held about quarterly with the entire team and product owner. At the start of any big project, the Scrum Master associated with the product and any contributing stake holders should also be included. Stake holder stories are a critical part of what eventually are done within a project, but just the team’s input is required on how the “epic” story is divided into stories that can be completed each Sprint. The Scrum Master needs to have a feel for the “epic” story and how this is divided into doable stories. The Scrum Master looks ahead a few sprints at a time to make sure everything is in place for the team to deliver a “potentially shippable product” at the end of each Sprint. It is a brain storming session only, without prioritizing any of the stories created. Stories generated here are either assigned to the next sprint or added to the Product Backlog. Remember, everyone’s opinion is important. Stories are turned into tasks that average one-day to implement. Some short stories may take an hour to complete, but if any appears to take more than 2-days, see if the story can divided. The goal is to have all story implementations completed within one Sprint. Use available tools to help create these stories, the main ones being those that show how the product will be used most efficiently. One process that would be helpful is Gemba.
3. Working Agreement – There are certain agreements that need to be made within the group of people who will be working together. A few of the basic ones are:
   1. Everyone’s opinion needs to be considered because it is important.
   2. Listen to each person, if needed have a way to give the floor to one person at a time.
   3. Live in the present, look for ways to work together now and not bring up old misunderstandings.
   4. Answer all team e-mails before going home at night.
   5. Meetings are rare and short, agree to pay a fine if late to one. Put the fines into paying for a fun event at the successful completion of the Sprint.
4. Product Backlog – Most often written in the form of stories that tell what the stake holders want the system to do and when they want the system to be delivered. This is from where the stories are taken that will be used in each Sprint. Backlog stories are often given difficulty ratings or time estimates on how long each phase (design/code/code review/test/automate test/document/…) will take. The product owner is responsible for the Product Backlog and prioritizing the needs for the solutions to each story. This input is used by the team to determine what will be the goal for each Sprint.
5. Product Backlog Refinement – If part of a Sprint, they are usually done during the Sprint Planning Meeting where the stories from the Product Backlog are presented by the Product Owner in the form of “epic” (large) stories. It is up to the team to decide how the stories would be divided to create more detailed stories that can be developed during a sprint.
6. Sprint – Fixed length of time to develop/code, code review, test, and delivery solutions to the stories selected for implementation. The number of stories selected for each sprint should be challenging but not impossible. The time is the key. If any stories are not completed by the end of the sprint, they are placed in the Sprint Backlog. At the end of a sprint, the product must be a “potentially shippable product” that forwards the progress of the total project in a high quality and tested release. The parts to a sprint are:
   

   Name	Description
   Sprint Planning	Done at the beginning of each Sprint. Determines what will be accomplished by the end of the Sprint. The Product Owner should bring about two Sprints worth of stories to this meeting to present to the team. This is where Planning Poker cards are used to determine the weight of each story and who is responsible for the completion of each story. If a story is too large to complete by the end of the Sprint, the team determines which part of the Story (or choose another Story) to be implemented. When planning, be sure to take into account Corporate Overhead and Unplanned Time (like emergencies and unexpected work where something takes longer than planned or some unforeseen defect is detected during testing) as well as the time spent working on the Stories assigned. Sprints should be a combination of Commitment and Velocity driven. As a team works together, they can determine how much work they can accomplish as a team (their velocity). From this, they can look at the Stories in the Product Backlog and the weight of each task, then calculate which Stories they can commit to solving before the end of the Sprint.
   Daily Scrum	Scrum.org defines it as “daily time-boxed event of 15 minutes, or less, for the Development Team to re-plan the next day of development work during a Sprint. Updates are reflected in the Sprint Backlog.” A 10-15 minute meeting is run with the Scrum Master and the Team daily to discuss any vital concerns (to avoid other meetings as much as possible). It is highly recommended that everyone stands during the meeting. Solving any problems should be left up to only the people directly involved and should be done outside this meeting. All stake holders and the Product Owner are invited to these meetings, but are not required to attend. Only members with a concern or vital status update should speak. Again, keep the overhead down to the minimum. When the best time to hold this meeting is determined by the Team. Daily Scrum is normally reserved for the short meeting, but there are some aspects of the daily work that are tightly connected with the Team succeeding. Work should be put into the project change control system each night, but should only be labeled with the current build tag when it has been unit tested to ensure that it has a low probability of breaking another part of the system. Informal communication should take place between team members to make sure each team member has the other pieces of the project to allow his/her portion to succeed (for example when library interfaces need to change/have changed, all affected people need to communicate when this is done). If there are tools that are needed, these needs need to be communicated to the Scrum Master. If changes to the automated (or manual) tests are needed by the updated code, these needs also must be informally communicated. The key is to have a “Potentially Shippable Product” at the end of each Sprint and, preferably, each day of the Sprint.
   Product Backlog Refinement	This is the start of the three meetings that normally need to take place at the end of each Sprint. Sprints are designed to cut down on the development overhead of more formal procedures. Therefore there are three meetings with only the needed attendees for the optimal length of time, normally minimal needed to accomplish the desired task. For the Product Backlog Refinement meetings, these meetings can be help as often as needed. For example, if they need to be held once per week then do so. These meetings are especially helpful for newly organized teams assigned to a new project. If some stories were not completed, these stories can be put into a higher priority Sprint Backlog or back into the Product Backlog if those stories can be put off until a later Sprint. With the help of the Scrum Master and Product Owner, the Product Backlog stories can be reviewed to determine which stories should probably be included on the next Sprint.
   Sprint Review	Like all Scrum meetings, efficiency is the goal. Cover what needs to be covered and do not waste time on doing something “because that is the way we have always done it.” For most Sprints, the meeting should be at most 4 hours long. The purpose of the meeting is “to solicit feedback and adjust the product backlog.” This is an informal meeting that includes the Team, Scrum Master, and Product Owner. The Stake Holders must be invited, but realize that they may not show up at the completion of each Sprint. The presentation should be informal with no slides. A brief demonstration of the product and the progress that was made is a nice feature. for the presenters, there should be at most two hours preparation time.
   Sprint Retrospective	The meeting is held at the end of each Sprint and lasts typically 30-60 minutes. This is the time to take a look at what is working and what is not working. Ask why to both, build on the answer of what is working and plan to change/improve what is not working. The Team, Scrum Master, and Product Owner participate. Be consistent with what you do with this information. It can be very effective in improving the quality of the Scrum process and make all future Sprints improve tremendously.

7. Sprint Backlog – These are derived from the selected Product Backlog that goes into defining specific Sprints. Stories are placed here when they need to be completed before the desired product can be delivered. Usually they are stories that were not able to be completed in the current Sprint or tentatively were planned for an upcoming Sprint.
8. Defects (Bugs) – When discovered, determine the cause and severity. If introduced in this Sprint, fix in this Sprint if there is time. If not enough time, put into the Sprint Backlog. If a discovered older defect, it should go into the Product Backlog and then ranked along with the other stories to determine when it will be fixed.
9. Task – Specific work that is part of implementing a story. There are many tasks involved in implementation a story. To implement all the tasks that create a story should be limited to an average of one-day. The story implementation cannot be shorter than one-hour just because of the overhead (even in a Scrum Sprint) and should not be longer than 2 days. Stories and tasks should either be “not started” or “done” and having an incomplete task from a story at the end of a sprint is a major concern.
10. Definitions of “Done” – Scrum.org defines it as “a shared understanding of expectations that software must live up to in order to be releasable into production. Managed by the Development Team.” It is vitally important that the product be “Potentially Shippable” at the end of each Sprint. The areas that can be done are:
    1. Planning – Product/Project Planning and Sprint Planning. Sprint Planning should be complete at the start of each Sprint. The high-level Product/Project Planning should be complete at its start. As the Sprints are executed, these plans need to be modified as more is known about the Product/Project. A good tool to use in the Product Planning process is Gemba.
    2. Analysis
    3. Design
    4. Coding
    5. Code Review
    6. Documentation
    7. Test – both initial manual and automated
    8. Performance
    9. User Acceptance Test
    10. Pilot
    11. Live

    Organization

    A Scrum is based on the rugby term, where a group of people advance a project through working together in SPRINTs on a specific set of stories (or tasks) that can be accomplished in a specific length of time. A large project has an overall goal. The Product Owner specifies what should be accomplished in the long term. The Scrum Master provides the framework and tools for the Team to accomplish the project one sprint at a time. The Team, with the help of the Scrum Master and Product Owner, decide what specific tasks should be done each SPRINT. Each SPRINT is one to four weeks long. The usual length is two weeks. Each SPRINT should be long enough to accomplish a significant amount of work to move the team closer to delivering the specified project. The Scrum Master and Product Owner help the team choose what are the most important tasks to complete in the next few SPRINTs. A totally detailed plan for the entire project is not specified, because as progress is made there will be changes needed in what needs to be done next. The purpose of a SPRINT is to accomplish as much work as possible in a fixed amount of time. When the SPRINT clock runs out, the SPRINT is done.

    Productivity

    The reason the Scrum Methodology was invented was to stream-line the development process. A Scrum Master has to ask if a certain activity helps or hinders the progress of the team in each Sprint. If the answer is helps, then do it. If the answer is hinders, then you need to ask yourself “what is the purpose of this activity?” For example, if you insist that you attend all meetings, even one-on-one meetings, you may be hindering the process. Of course this is obvious for team members meeting with each other. However, some Scrum Masters insist that they attend all meetings between the Product Owner and any Team Member. Some of these meetings relay vital information to the developer and can be very short. What is the purpose of you being there? Are you truly helping the product be produced faster? If this is not the case, then maybe attending every meeting is not a good use of your time. Think about the consequences. The Scrum Masters job is to help the Sprints be challenging and to get them done on-time with a “potentially shippable” product.