Scrum

Scrum Framework

People often think Agile and Scrum are the same thing because they are both centered around continuous improvement, which is a core principle of agile. However, Agile is a mindset, where Scrum is a framework for getting work done. An Agile transition takes dedication from the whole team to change the way they think about delivering value to your customers. You can however use a framework like Scrum to help you start thinking that way and to practice building agile principles into your everyday work practices and communication.

The scrum framework is empirical; it’s based on continuous learning and adjustment to varying factors. It recognizes that the team doesn’t know everything at the onset of a project and will evolve through experience. The framework is designed to help teams naturally adapt to user requirements and changing conditions, with a process of re-prioritization and short release cycles so your team can continuously adapt and improve.

Structure is a part of Scrum; however, it is not rigid. It can be tailored to the needs of any organization. At BeardedEagle we are aware that there are many different technics to teach people about Agile and Scrum. We’ve learned that transparency, clarity and caring about the success of our students must always be the core of our organization.

Let’s Start with Scrum Artifacts

We are going to identify the three artifacts in Scrum. The Artifacts can be viewed as tools to help solve a problem. The three artifacts in Scrum are a product backlog, a sprint backlog, and an increment with your definition of “done”. The three Scrum Artifacts are the constants in a Scrum team that we continuously revisit and invest in.

• Product Backlog is the master list of work that needs to get done. It is maintained by the product owner or product manager and is essentially the team’s “To Do” list. This is a list of features, requirements, enhancements, and fixes that acts as the input for the sprint backlog. The product backlog is revisited, re-prioritized and maintained by the Product Owner constantly because, the market changes ad as we learn more, relevancy could become an issue or problems get solve in alternate ways.
• Sprint Backlog is the list of items, user stories, or bug fixes, selected by the development team for implementation in the current sprint cycle. Before each sprint, in the sprint planning meeting the team chooses which items it will work on for the sprint from the product backlog. A sprint backlog may be flexible and can evolve during a sprint. However, the fundamental sprint goal – what the team wants to achieve from the current sprint – cannot be compromised.
• Increment (or Sprint Goal) is the usable end-product from a sprint. You may not hear the word “increment” out in the world, as it’s often referred to as the team’s definition of “Done”, a milestone, completed the sprint goal. “Done” depends on how your teams defines the completion of a sprint goal. Some teams may choose to release a product to their customers at the conclusion of every sprint, therefore their definition would be ‘shipped’. However, this may not be realistic of other types of teams. Say you work on a server-based product that can only ship to your customers every quarter. You may still choose to work in 2-week sprints, but your definition of ‘done’ may be finishing part of a larger version that you plan to ship together.

As you see, there are lots of differences, even within artifacts, that your team can choose to define. It’s important to be open to evolving how you maintain even your artifacts. Maybe your definition of ‘done’ provides undo stress on your team, and you need to go back and pick a new definition.

Scrum Events

Some of the more well-known components of the Scrum framework are the set of events, or meetings that scrum teams perform on a regular basis. The events are where there are variations for teams. Some teams find doing all of these events burdensome and repetitive, while others use them as a necessary check in. You can perform a quick retro and see if and where adjustments are necessary.

Key Scrum events:

1. Organize the backlog:  this event is the responsibility of the product owner. The product owner’s main jobs are to drive the product towards its product vision and have a constant pulse on the market and the customer. Therefore, he/she maintains this list using feedback from users and the development team to help prioritize and keep the list clean and ready to be worked on at any given time. You can read more about maintaining a healthy backlog here.
2. Sprint planning: The work to be performed (scope) during the current sprint is planned during this meeting by the entire development team. This meeting is led by the scrum master and is where the team decides on the sprint goal. Specific use stories are then added to the sprint from the product backlog.  These stories always align with the goal and are also agreed upon by the scrum team to be feasible to implement during the sprint.At the end of the planning meeting, every scrum member needs to be clear on what can be delivered in the sprint and how the increment can be delivered.
3. Sprint: A sprint is the actual time period when the scrum team works together to finish an increment. Two weeks is a pretty typical length for a sprint, though some teams find a week to be easier to scope or a month to be easier to deliver a valuable increment. Dave West, from Scrum.org advises that the more complex the work and the more unknowns, the shorter the sprint should be. But it’s really up to your team, and you shouldn’t be afraid to change it if it’s not working! During this period, the scope can be re-negotiated between the product owner and the development team if necessary. This forms the crux of the empirical nature of scrum.All the events — from planning to retrospective — happen during the sprint. Once a certain time interval for a sprint is established, it has to remain consistent throughout the development period. This helps the team learn from past experiences and apply that insight to future sprints.
4. Daily Scrum or Stand Up: This is a daily super-short meeting that happens at the same time (usually mornings) and place to keep it simple. Many teams try to complete the meeting in 15 minutes, but that’s just a guideline. This meeting is also called a ‘daily stand-up’ emphasizing that it needs to be a quick one. The goal of the daily scrum is for everyone on the team to be on the same page, aligned with the sprint goal, and to get a plan out for the next 24 hours.The stand up is the time to voice any concerns you have with meeting the sprint goal or any blockers.
   
   A common way to conduct a stand up is for every team member to answers three questions in the context of achieving the sprint goal:
   • What did I do yesterday?
   • What do I plan to do today?
   • Are there any obstacles?

   However, we’ve seen the meeting quickly turn into people reading from their calendars from yesterday and for the next day. The theory behind the stand up is that it keep distracting chatter to a daily meeting, so the team can focus on the work for the rest of the day.  So if it turns into a daily calendar read-out, don’t be afraid to change it up and get creative.

5. Sprint review: At the end of the sprint, the team gets together for an informal session to view a demo of, or inspect, the increment. The development team showcases the backlog items that are now ‘Done’ to stakeholders and teammates for feedback. The product owner can decide whether or not to release the increment, although in most cases the increment is released.This review meeting is also when the product owner reworks the product backlog based on the current sprint, which can feed into the next sprint planning session. For a one-month sprint, consider time-boxing your sprint review to a maximum of four hours.
6. Sprint retrospective: The retrospective is where the team comes together to document and discuss what worked and what didn’t work in a sprint, a project, people or relationships, tools, or even for certain ceremonies. The idea is to create a place where the team can focus on what went well and what needs to be improved for the next time, and less about what went wrong.

Three Key Scrum Roles

There are three specific roles a Scrum team needs product owner, scrum master, and the development team. Traditionally, Scrum teams are cross-functional, the development team can include people in various roles depending on the type of organization.

The scrum product owner

A Product Owner in the Scrum Framework is the single person who is responsible for the success of a Product and for maximizing the value of that Product. In the Scrum Framework, a few of the Product Owners’ responsibilities are described, such as Product Backlog management, maximizing value and stakeholder management Effective product owners:

• Develop and manage the product backlog.
• Work closely with stakeholders, and the team to ensure everyone understands the work items in the product backlog.
• Give clear guidance to the team on which features to deliver next.
• Decide when the product is done and ready for delivery.

The product owner is not always the product manager. Product owners focus on ensuring the development team delivers the most value to the business. Also, it’s important that the product owner be an individual. No development team wants mixed guidance from multiple product owners.

The Scrum Master

The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

An effective scrum master deeply understands the work being done by the team and can help the team optimize their transparency and delivery flow. As the facilitator-in-chief, he/she schedules the needed resources (both human and logistical) for sprint planning, stand-up, sprint review, and the sprint retrospective.

Roles a Scrum Master Plays

Service to the Product Owner

The Scrum Master serves the Product Owner in several ways, including:

• Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible.
• Finding techniques for effective Product Backlog management.
• Helping the Scrum Team understand the need for clear and concise Product Backlog items.
• Understanding product planning in an empirical environment.
• Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value.
• Understanding and practicing agility.
• Facilitating Scrum events as requested or needed.

Scrum Master Service to the Development Team

The Scrum Master serves the Development Team in several ways, including:

• Coaching the Development Team in self-organization and cross-functionality.
• Helping the Development Team to create high-value products.
• Removing impediments to the Development Team’s progress.
• Facilitating Scrum events as requested or needed.
• Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.

The Scrum Master serves the organization in several ways, including:

• Leading and coaching the organization in its Scrum adoption;
• Planning Scrum implementations within the organization;
• Helping employees and stakeholders understand and enact Scrum and empirical product development;
• Causing change that increases the productivity of the Scrum Team; and,
• Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.

The scrum development team

The Scrum Team gets the work done! They are advocates for sustainable development practices. Generally effective Scrum Teams consist of 5-7 members, co-located and working together to deliver the required product increments.

Team members have varied skills, and avoid the horrid bottleneck effect by cross-training each other. With the help of all team members, the self organizing group approaches each project with a clear agenda to ensure success.

The scrum team creates and drives the plan for each sprint. They control the forecast of the amount of work that can be completed during the iteration. A fixed length gives the development team important guidelines for estimation and the delivery process, which in turn makes their forecasts increasingly accurate over time.

Now You Ask, Why Scrum?

Why Scrum? Because it is a simple effective framework. It has easy straightforward rules, artifacts, roles and events to understand. Scrum is easily adaptable to any industry, and ideal for projects of varying degrees of difficulty.

The distinction of planned events and roles ensure transparency and group ownership throughout the development cycle. Escalated delivery times keeps motivation among the team and happy stakeholders.

Scrum’s success and adaptability across diverse industries and verticals makes it an ideal framework to adopt for any organization.