After dealing with countless questions regarding the Scrum framework and how it works in the real world, let’s take a few minutes to talk about the Scrum framework. I’ll be doing my best to stick to what is covered in The Scrum Guide and by what is tested in Scrum.org’s Professional Scrum Master exams. I will also be assuming only a single Scrum Team will work on a product. In later posts, we’ll discuss more of the real-world applications Scrum, scaling Scrum to multiple teams and practical examples of how your team can use the inspect and adapt cycles offered by the Scrum framework. As well, we’ll explore other Agile management techniques such as Extreme Programming (XP), SAFe and Kanban.

It’s best for you and your team to start the Scrum journey using the core framework in its entirety without alteration. As your team becomes more mature your development process will improve. Keep in mind your team’s first few sprints are going to be terrible, especially on inexperienced teams. Don’t be discouraged if you don’t immediately see improvements in your product from the change in your software development process. From my experience, it takes a month or two for a team to get into the groove, but it may take longer. The important part is that you’re consistent and avoid alterations to the framework.

What is Agile?

Agile or more properly, Agile Software Development, is a group of software development methodologies which embody the concepts outlined in the Agile Manifesto. Agile Software Development strives to deliver high-quality customer centric software in an iterative process. Agile embraces the idea that you will never have all the information needed to implement a feature or change until just before it is implemented. We need to embrace and trust our team can solve problems as they arise and not worry about planning every detail in the beginning phases of the project.

Agile teams should contain all roles needed to develop a feature into a potentially shippable increment of the product; this can include, but is not limited to, front-end developers, back-end developers, operations staff, compliance, financiers, quality assurance and business analysts. Such diverse Agile teams are commonly referred to as cross-functional teams. By organizing teams with a varied skill set, you set up the team to be able to inspect and adapt the product as well as the development process based on customer feedback and the ever-changing landscape of your product’s market.

What is Scrum?

Scrum is an Agile framework created by Jeff Sutherland and Ken Schwaber based on empirical process control theory or empiricism. Scrum’s goal is to help teams develop complex applications while being able to adapt to changing market conditions and opportunities. Scrum is meant to replace more traditional software development processes such as Waterfall. Scrum accepts that a Development Team will not know all the information about a product or individual work item before work is begun. The focus of Scrum is on inspection and adaptation of both the product and the process instead of exhaustive requirement gathering and writing extremely detailed specifications.

The Scrum framework is comprised of roles, event, artifacts and rules. We’ll explore roles, events and artifacts specifically, while the rules will be sprinkled in through the explanations of the other aspects of the Scrum framework. It’s also important to point out the three pillars of Scrum are inspection, adaption and transparency. The inspection and adaption pillars of the framework are the theoretical basis for the Scrum events. Transparency comes into play with the team’s process, definition of “Done” and the artifacts. Be aware officially transparency means significant aspects of the process should be visible to those who are responsible for the outcome but the whole process maybe too much information for groups such as stakeholders.

It’s expected the organization’s management will trust the Scrum Team and allow them to operate as autonomously as possible. Scrum’s team model is designed to optimize the flexibility, creativity and productivity of the team. Scrum Teams are cross-functional and are responsible for choosing how to best accomplish their work without being directed by anyone outside of their team. Management and key stakeholders have access to the Scrum Team through the Product Owner and the Sprint Review event. While trusting the Scrum team may sound scary, I’ve found the teams I work with are far more capable than I am to make product implementation decisions and never cease to surprise me with their creativity and sense of responsibility for delivering a high-quality product.

What Should I Expect from Scrum?

This is where I’m supposed tell you that everything is going to be sunshine and rainbows, that you’ll see a 100x increase in team performance within the first week and a 15% reduction in your car insurance. Sorry to burst your bubble, but that simply not true, it’s going to be hard to stick to the framework and most likely it’s going to be an uphill battle to get full organizational support for implementing Scrum. Not to mention the difficulty in finding where your team needs to improve their process to make up for the not-so-stellar development practices they may have had before. Ultimately, the Scrum framework is the basis for the process which your team is responsible to create and optimize. Each team’s implementation will be slightly different because each organization and Scrum Team will have their own quirks and face their own unique set of challenges. While I cannot guarantee you’ll see massive improvements in the specific set of metrics you’re trying to improve, I can tell you from my experience, every team I’ve worked with has seen an improvement in product reliability, product adaptability, development cost and the team’s ability to give meaningful timelines.

Core Concepts

Before we can jump into the meat of the Scrum framework, events, roles and artifacts, we need to discuss some of the general terms and concepts. The heart of the Scrum framework is the Sprint, a fixed length of time where the Scrum events are contained and the Development Team completes work as described in the Sprint Backlog to achieve the Sprint Goal while producing a potentially shippable Increment of the product. Sprints have an artifact called the Sprint Backlog which contains work from the Product Backlog artifact. Scrum does not define exactly what the work should look like beyond it having value to the users of your product. It is recommended that your team uses the common Agile increment of functionality, the user story or it’s more common name, story. Stories describe a unit of desired functionality from the perspective of a user. In Scrum, each story has a scope associated with it, known as a Definition of Done, which is an extension of the overall product’s Definition of Done.

In addition to the Sprint it’s important we discuss what I regard as the most important concept in Scrum, timeboxing. A timebox describes the maximum amount of time that can be spent an aspect of the framework. Timeboxes exist to help manage risk and prevent spending too much time on the process instead of feature development. In addition to timeboxing, Scrum emphasizes accountability, one way you can do this is by tracking velocity. Velocity is the amount of work completed and put into a potentially shippable Increment each Sprint.

Sprint

A Sprint, also known as an Iteration, is a Scrum event which occurs on a fixed cadence where the Scrum Team will create a Sprint Goal, complete all the Scrum events and complete the work in the Sprint Backlog. At the Sprint’s conclusion, your team should have created a potentially shippable product Increment with the work completed during the Sprint.

Sprints should be no shorter than one week and no longer than four weeks. Sprint length is based on what the Product Owner believes is an acceptable level of risk. The Product Owner should look at this as how quickly the Scrum Team will need to respond user feedback or changes in the market. Generally, the shorter the Sprint the faster a team can respond to changing market conditions. However, short Sprints tend to spend larger proportion of time on process and can make it hard for the Scrum Team to get into a development groove. It’s really a balancing act between how quickly you need to be able to respond to market conditions and how much time you want to spend on process. As a result, most teams prefer two-week Sprints.

It can be extremely tempting to change the length of Sprints based off how quickly the Sprint Backlog is completed or your position in the product life cycle. For instance, you’d like longer Sprints when the product is still in the main part of development and shorter Sprints immediately after the product is launched to the public. Unfortunately, Scrum is extremely particular on this point, Sprints must be a reliable length because anytime uncertainty is introduced into the process you will reduce your team’s output. While a Scrum Team can technically change the length of their Sprints if they feel it would be best based off their recent experience and problems raised during the Sprint Retrospective, Sprint length should not vary from Sprint to Sprint. Ultimately, any change to Sprint length happens extremely rarely, if at all.

Sprint Goals are crucial for setting the tone of what is expected at the end of the Sprint. A good goal is vague but can be accomplished by completing work from the Product Backlog. Your team will be responsible for creating the Sprint Goal during the Sprint Planning event, so we’ll discuss goal formulation in more detail there. Be aware, once a Sprint has begun the Sprint Goal may not be changed nor may the team make any changes to the Sprint which would endanger the Sprint Goal.

Sprints maybe cancelled at any time should the Product Owner no longer believe the Sprint Goal and, by extension, the Sprint will lead to a user-beneficial potentially shippable Increment. Cancelling a Sprint should be exceedingly rare and should not be taken lightly. While the Product Owner has the sole power to make this decision, it is in the best interest of the Product Owner to consult the Development Team before cancelling a Sprint. Arbitrarily cancelling a Sprint will most likely undermine the trust between the Product Owner and the Development Team. If a Sprint is canceled the Product Owner must review the completed stories and should accept the stories which meet the Definition of Done. Any remaining stories should be placed back into the Product Backlog and either re-estimated or killed.

At the end of each Sprint, the team will create a potentially shippable Increment of the product. Potentially shippable means that the Increment may be released to users at the end of the Sprint, but is not required to be released. The Product Owner has the sole power to release the product when they decide the new product Increment is the most likely to succeed in the market.

If at any time the Development Team believes they will be unable to complete the work they committed to in the Sprint Backlog, they may discuss removing work from the Sprint with the Product Owner, the final decision for any rescopes lies with the Product Owner. On the other hand, if the team completes all the work early, the Sprint will remain intact and the Development Team will work with the Product Owner to add new work which aligns with the Sprint Goal from the Product Backlog to the Sprint Backlog.

The Scrum Guide considers the Sprint to be a Scrum event. While I don’t disagree, I have separated the Sprint from the other Scrum events in my Scrum framework explanation because the Sprint acts as the container for all other events.

Timeboxing

Scrum is very particular about how much time should be spent on each event in the framework. It doesn’t entirely matter what timeboxes are set at, what does matter is that they are predictable and enforced. The only exception is the Daily Scrum which should always be 15 minutes. The recommendations of timeboxes from the Scrum guide are a good starting point.

• Daily Scrum: 15 minutes
• Sprint Planning:  2 hours per week of Sprint (i.e. 8 hours for single month Sprint)
• Sprint Review: 1 hour per week of Sprint (i.e. 4 hours for a single month Sprint)
• Sprint Retrospective: 45 minutes per week of Sprint (i.e. 3 hours for a single month Sprint)

Be aware if your Scrum Master and your Development Team do not stay on top of the timeboxes you will create unnecessary overhead and make it harder for your team to successfully accomplish the Sprint Goal. If your Scrum Team feels an idea or impediment wasn’t properly addressed during the timebox, your team can schedule an additional meeting. This meeting should also be timeboxed based off the expected complexity. While Scrum doesn’t place limits on meetings outside of the events it does state that all additional meetings must somehow relate to the completion of the Sprint Goal.

Stories

The story is the core unit of work in Agile processes. Stories are meant to describe what the experience should be from a specific perspective. Generally, you’ll look from the perspective of a user, however, as your product evolves you may find it useful to break users into different roles and each story may target one or more roles. While it can be tempting for a story to describe the exact changes required, story implementation details are at the discretion of the Development Team in Scrum. The Product Owner, who is responsible for stories in the Product Backlog, may only use a story to describe the desired functionality, the context of the story and what they expect for the story to be considered complete. The story’s Definition of Done is an additional layer on top of the general product level of the Definition of Done. The Product Owner may give an example implementation if it can help to explain the desired functionality, but there is no guarantee the Development Team will use that implementation. I’ve found it helpful to adopt an idea from Extreme Programming and treat a story as a reminder for a conversation which should occur between the Product Owner and the Development Team. At the end of the conversation the Development Team should have a clear idea of what problem the story is trying to solve as well as what is expected from them for that story to be considered done. The Product Owner should be aware of any tradeoffs which may need to be made in the completion of that issue and any additional improvements to the story the Development Team has identified.

At the most basic level, stories should be written in an active voice and from the perspective of the role you are trying to improve. Your team should also ensure stories are independent of one another and are completable. I plan on doing a future deep-dive on story creation, estimation and scoping in the future, so we’ll stick with this cursory overview. There are also many good books on the subject such as User Stories Applied: For Agile Software Development.

Definition of Done

It may seem trivial but having a product, team and/or organization Definition of Done is crucial for the success of a product. The Definition of Done allows your team to set down what it means for a story to be potentially shippable. The product level Definition of Done is where you’d set down your minimum platform support requirements, performance requirements, stability requirements, testing requirements, etc. Basically, if you find yourself adding the same requirements to all stories or continually discussing the same problems at the Sprint Retrospective then it is probably a good candidate to be added to your product Definition of Done.

The Development Team may update the Definition of Done as additional requirements or organizational values are uncovered.

Velocity

To judge your team’s improvements in Sprint performance while using the Scrum framework it’s a good idea to track the team’s velocity. Velocity is how many ideal developer days, story points or another per story measurement which has been or expected to be completed in a Sprint. I highly recommend using story points, but estimating stories can be a massive rabbit hole, we’ll discuss story points in more detail a future post.

Velocity is expected to remain constant or increase each iteration. Your team should have an idea of what their expected velocity will be for each Sprint. Expected velocity should be adjusted based off the amount of available developer hours for the Sprint. While it is maybe tempting to chastise individual developers for not hitting a their “portion” of the expected velocity, a single developer should never be held accountable for proportional velocity. The entire Development Team is responsible for velocity and completing the Sprint. It is the Development Team’s responsibly to make sure each team member accountable for individual performance.

If you are running your first few Sprints you will most likely not have any idea what your team’s velocity will look like. If you are working with an experienced Development Team then you can try to extrapolate velocity based off the performance from their last projects. Be aware velocity from one team is not directly applicable to another team, even if it’s the same developers in the same organization but they’re developing a different product. Finally, if you’re working with a completely new team unfamiliar with Scrum, then make up a velocity and adjust it based off the performance from the first few Sprints.

Scrum Artifacts

Artifacts are groupings of work created as a part of the Scrum framework. The primary purpose of artifacts is to capture and show the team’s understanding of the product at the time the artifact is created. Scrum defines the Scrum artifacts as the Product Backlog, Sprint Backlog and Increments.

Product Backlog

The Product Backlog is the definitive list of known work to add additional value to the product. A single product will only ever have a single Product Backlog. The Product Backlog will never be “complete”, the goal of the Product Backlog is to show the current known state of the product and its opportunities.

The Product Owner is responsible for the Product Backlog, breaking down Product Backlog items and ordering the Product Backlog. They may delegate Product Backlog changes to other members of the Scrum Team, but the Product Owner should understand what each work item entails and the business value. The Product Backlog must be ordered such that the most valuable, well-defined, stories appear at the top of the backlog. The Product Owner should always be consulting users, stakeholders and the Development Team to understand the Definition of Done and business value of each story.

While the Product Backlog is owned by the Product Owner, the Product Backlog should always be available for viewing by any member of the team or organization. While your team may be legally unable to make the complete Product Backlog available to everyone in the organization due to compliance issues, you should do your best to make sure it is as available as it can be. At an absolute minimum, the full Product Backlog must be available to all member of the Scrum Team.

Please note that your Product Backlog will look very different on the first day of the project than it will many years into development. For instance, at the beginning of the product you should expect to see a lot of new functionality stories whereas later in the project you’d expect to see a larger proportion of functionality update stories.

Sprint Backlog

The Sprint Backlog is a subset of the Product Backlog along with additional work the developers deem necessary to accomplish the Sprint Goal. Product Backlog items are added to the Sprint Backlog during the Sprint Planning event. The Development Team has sole ownership of the Sprint Backlog after the Sprint Planning event.

During the Sprint, the Development Team may discover new work needed to accomplish the Sprint Goal, the work should be added to the Sprint Backlog as soon as it is discovered. The Development Team may update or remove any work which they have created. If the Development Team wishes to remove a Product Backlog item from the Sprint Backlog, they must get approval for the rescope from the Product Owner.

As a note, it’s expected that items in the Sprint Backlog will be smaller than most items in the Product Backlog. This is because Product Backlog items added to the Sprint Backlog should be more finitely scoped than those which may exist in the Product Backlog.

Increment

At the end of every Sprint the Development Team should produce a potentially shippable Increment. An Increment is sum of all work which has been completed during the Sprint and the value created during all previous Sprints. Essentially, an Increment is a shiny new version of the full product which must be able to be released to users. The new Increment must meet the Definition of Done for the product and each work item included must meet their individual Definitions of Done.

The decision of when to release an Increment of the product falls with the Product Owner and does not need to line up with the end of a Sprint. The only restriction is that the Product Owner may never release an Increment with in-progress work. Critical bugs throw a wrench into this and must be dealt with on a case-by-case basis and the ultimate responsibility for what to do falls on the Product Owner in consultation with the Development Team.

Scrum Roles

Roles in Scrum describe what the responsibility of Scrum Team members are. On a Scrum Team, you’ll have the Product Owner, the Scrum Master and the Development Team. Outside of the Scrum Team you’ll have other roles such as stakeholders and customers. While I won’t go into detail on roles outside of the Scrum Team, they are extremely important. Your team is building the product for customers and stakeholders, so it’s the team’s job to deliver value to the customer and the stakeholders even if those people are not on the Scrum Team.

Development Team

These are the people who will be doing the work for the Scrum Team. In Scrum, there is no concept of developer hierarchy, all members of the Development Team carry the title of developer and are equal in the eyes of the Scrum Team. With team member’s being on a level playing field it allows team members to hold each other accountable, which is essential for teams to be cross-functional and self-organizing.

For the Development Team to be cross-functional they must have all the skills required to take a story and turn it into a potentially shippable Increment. The Development Team self-organizes through being responsible that successfully completing the work in the Sprint Backlog means the Development Team will have accomplished the Sprint Goal. As a part of self-organizing the Development Team will also be responsible for the estimation of issues in the Product Backlog. Self-organizing helps to increase team buy-in, accountability and creativity.

All developers are responsible for tracking the likelihood the Sprint will be successful in achieving the Sprint Goal and ensuring the Sprint Goal is accomplished by the end of the Sprint. No work in the Sprint Backlog belongs to any single member of the Development Team, the work belongs to the entire Development Team. However, it can be helpful to “assign” work to individual team members so long as the team is aware the entire team will be held accountable for the delivery of the work.

The Development Team should be composed of between three and nine developers. Usually Scrum Development Teams work best with about five developers. The Product Owner and Scrum Master are not counted in the number of developers unless they are performing work from the Sprint Backlog. The upper and lower limit exist to ensure coordination of team members and ensure the team is cross-functional.

It should be noted that a Development Team does not need to be dedicated to a single project, however it is recommended a Development Team only works on one project at a time. As well when a project is large enough to require more than nine people on a Development Team, then you should be using multiple Scrum Teams with a shared Product Backlog instead of a single Scrum Team composed of many sub-Scrum Teams.

Scrum Master

The Scrum Master is a servant-leader and is responsible for helping the Development Team, the Product Owner and the stakeholders with Scrum. Scrum Masters exist to help maximize both the value created by the Scrum Team and the value created with interactions between the Scrum Team and non-Scrum Team members. While a Scrum Master maybe a manager in the organization they are discouraged from being responsible for hiring or firing members of the Development Team. The Scrum Master is also responsible for ensuring Scrum events occur, timeboxes are respected and Scrum artifacts are transparent.

The Scrum Master primarily serves the Development Team by coaching, facilitating Scrum events and removing impediments. Coaching generally covers the Scrum framework, self-organization, cross-functionality and the process of creating high-quality products. As a part of this coaching process the Scrum Master can be asked by the development team to help facilitate the Scrum events by showing Scrum Retrospective techniques, demonstrating how to run a Daily Scrum, etc. The most important services the Scrum Master performs for the Development Team is removing impediments and facilitating decisions.

The Scrum Master serves the Product Owner by helping them with the management of the Product Backlog, understanding product planning in an empirical environment and coaching the Product Owner on their aspects Scrum framework. Generally, the Scrum Master provides Product Backlog management support through recommendations on Product Backlog management techniques, helping write clear, implementable stories and ensuring the Product Backlog is organized to maximize value.

The Scrum Master serves the stakeholders and organization through coaching on the Scrum framework, coaching on the adoption of the Scrum framework, increasing the productivity of the Scrum Team and working with other Scrum Masters to increase the effectiveness of Scrum in the organization. The Scrum Master is also responsible for ensuring the organizational management respects the boundaries put in place to protect the Scrum Team’s developers from distractions.

Ensuring artifact transparency is the final aspect of the Scrum Master role. Scrum Masters ensure artifacts are transparent by learning, convincing and helping to change the Scrum Team and organization. Artifact transparency is extremely important because it keeps the Scrum Team honest and accountable.

The Scrum Master role is arguably the hardest role on a Scrum Team due to the requisite knowledge of the Scrum framework, technical knowledge and intrapersonal skills. Scrum Masters are expected to learn, discuss and convince, not intimidate or demand. I believe experienced Development Team members with an aptitude for building interpersonal relationships are the best candidates for the Scrum Master role.

Product Owner

The Product Owner is responsible for the vision of the product, ensuring the product meets the needs of the organization and the Development Team is only working on the most valuable stories from the Product Backlog. Key characteristics of the Product Owner are, ability to maximize the value of the product, experts in the product’s market and keep the stakeholders involved in the project.

The largest single responsibility the Product Owner has is Product Backlog management. They need to clearly communicate the expectations of a story, order the Product Backlog for maximum value, ensure the Product Backlog stories are understandable enough to the Development Team, ensure the Product Backlog is transparent and the Product Backlog clearly communicates what the Scrum Team will work on next. The Product Owner may ask the Development Team to help with aspects of their responsibly, but the Product Owner is still accountable for the work being done.

The Product Owner must be a single person and not a team of people. When teams are introduced it becomes harder to keep the Product Owner accountable and consistent. The Product Owner should represent voices both inside and outside of the organization, but only have a single voice. It is also extremely important the organization trust the judgement of the Product Owner and respect their decisions and autonomy. The Product Owner is the only individual who can change the direction of the Development Team or directly affect the Development Team.

Scrum Sprint Events

Scrum has four prescribed events which occur during a Sprint, Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective. Note the events are in order of occurrence during the Sprint. Each of the events plays an important part in allowing you to inspect and adapt and should not be skipped. It is the Scrum Master’s responsibility to ensure Scrum’s prescribed events are occurring.

Sprint Planning

Sprint Planning occurs at the beginning of the Sprint and requires the participation of the entire Scrum Team. Sprint Planning is timeboxed to eight hours for a one-month sprint and should be scaled proportionally to match your team’s Sprints. A two-week Sprint should be expected to take a maximum of four hours to plan. During Sprint Planning the Scrum Team is responsible for formulating a Sprint Goal, populating the Sprint Backlog with stories from the Product Backlog to accomplish the Sprint Goal and decomposing the first day’s work into individual work items which can be completed in one day or less. Please note that Product Backlog items must be estimated before they can go into a Sprint Backlog. Estimations fall on the shoulders of the Development Team and should take no longer than 10% of the Development Team’s time. The Development Team estimate working in the Product Backlog at any time during the Sprint.

The formulation of a Sprint Goal is extremely important. It tells the team why they are creating the potentially shippable Increment of the product. The Sprint Goal should be vague enough to allow for some flexibility in what features can be implemented during the Sprint, but should also provide enough structure to give context to all features developed during the Sprint. While it may be tempting to formulate a Sprint Goal such as “Fix bugs” or “Stabilize the product” these are not allowed and indicate a failure in your team’s Definition of Done.

After the Scrum Team agrees on a Sprint Goal, the Development Team should agree on how much work they believe they can perform in the Sprint based off past velocity and the team’s availability for the Sprint. Then the Development Team and the Product Owner are expected to negotiate which estimated Product Backlog items are going to be moved from the Product Backlog to the Sprint Backlog, each story moved should help the team accomplish Sprint Goal. Preference is given to Product Backlog items which appear higher in the Product Backlog.

The Development Team may invite people from outside of the Scrum Team to provide technical or domain advice. Doing so does not violate the concept of cross-functionality as the Development Team is asking for advice and not asking for additional work to be done. If the Development Team requires a subject matter expert for the implementation of a story, a person may be temporarily added to the Scrum Team for the duration of the Sprint. The temporary addition carries the same responsibilities as the other members of the Development Team.

At the end of the Sprint Planning session the Development Team should be able to explain how they intend to self-organize to complete the Sprint Goal and deliver a potentially shippable Increment of the product. If the Development Team did not create a plan to complete all the work in the Sprint, it is expected they will do so throughout the Sprint.

A note on estimations, generally, teams use story points to represent how much work they believe a story will take. A story point is an arbitrary value added to a story based off an educated guess of expected complexity. It is discouraged to tie story points or any estimations directly back to developer hours. This is because your estimates will be off no matter how much time is spent on them. Estimates should strive to be consistent for stories with similar expected complexity, not accurate. Consistency allows for a more accurate assessment of velocity.

Daily Scrum

The Daily Scrum, also known as the Daily Stand-up or just Stand-up, occurs each working day and acts as an opportunity for the Development Team to communicate status, identify impediments, improve the Development Team’s shared knowledge and promote quick decision-making. Only the Development Team is required to attend and participate. While other members of the organization may attend, they are not allowed to participate unless asked a question by the Development Team.

During the Daily Scrum, each developer should cover the following questions:

• What did I do yesterday to help the team complete the Sprint Goal?
• What will I do today to help the team complete the Sprint Goal?
• Do I see any see any impediments which could cause myself or the team miss the Sprint Goal?

Impediments are anything which can prevent your Development Team from accomplishing the Sprint Goal. Examples of impediments are disproven assumptions, security risks, vendor issues, etc. It is the responsibility of the Scrum Master, when in attendance, to take note of the impediment and who is tasked with completing it. The Scrum Master should also make impediment assignment information available through the team’s Sprint Backlog or another location which is available to the entire team.

It is extremely important that the Daily Scrum takes no more than 15 minutes to complete and occurs at the same time and place each work day. The Daily Scrum should occur on-time regardless if all Development Team are present. The Daily Scrum is owned by the Development Team and thus it is their responsibility to ensure it is happening as prescribed. It is also the responsibility of the Scrum Master to ensure the Daily Scrum is happening.

While Product Owner and Scrum Master do not need to be present, although, it is in the best interest of the Scrum Team for them to be in attendance to answer questions when prompted. The Daily Scrum is not intended to solve problems, it is for identify their existence. If a problem needs to be solved in another meeting scheduled sometime after the Daily Scrum has concluded.

Sprint Review

Sprint Reviews happen at the end of a Sprint and should take four hours for a one-month Sprint or proportionally less for shorter Sprints. The Scrum Team as well as stakeholders invited by the Product Owner are required to participate. The Sprint Review is meant to act as an opportunity for the Scrum Team to demonstrate the potentially shippable Increment, communicate the project’s progress and receive feedback from stakeholders. While a Sprint Review does demonstrate an Increment, it is considered an informal meeting and should not be treated as a traditional status meeting.

The Sprint Review should start off with the Product Owner explaining the Sprint Goal and what Product Backlog stories have been completed during the Sprint. Then the Development Team demonstrate the work they completed as a part of the Sprint. The Development Team should also discuss any challenges they faced and how they solved the issues. The Product Owner should then discuss the current standing of the Product Backlog and communicate any timelines or additional information the stakeholders would like during the Sprint Reviews. Finally, the entire group should discuss what should be accomplished in future iterations, any known market opportunities and any other topics the stakeholders wish to cover.

Sprint Reviews should not be the only place feedback is received, but it should be used as a recurring forum for communication about the product and the organizational needs it is filling.

Sprint Retrospective

Sprint Retrospectives should happen after the Sprint Review but before Sprint Planning. During this event, the Scrum Team takes some time to privately inspect and adapt itself and create a plan for improvements to be implemented in the next Sprint. The Sprint Retrospective has a three-hour timebox for a one-month Sprint and proportionally less for shorter Sprints. Your entire Scrum Team is expected to participate.

When the Scrum Team is inspecting itself, it should be looking at how the last Sprint went in terms of people, relationships, process and tools. This is done by the Scrum Team creating and ordering two lists of major items, one for what went well and the other for what could be potentially improved. At the end, your team should agree on the top one or two potential areas of improvement and discuss what the team can do to improve these major items. The Scrum Team is expected to have a plan on a way to improve the top areas of improvement as you will be implementing the improvements during the next Sprint. The Development Team may update the Definition of Done based off the Sprint Retrospective regardless of it being identified as a top area of improvement.

At a high level, the Scrum Team should be respectful of one another, the Sprint Retrospective isn’t about airing dirty laundry, it’s about identifying problems and fixing them, resist playing the blame game. The team should keep track of all major items generated during the Sprint Retrospective, it will be helpful to refer to previous Sprint Retrospectives from time to time. The team should also be looking at the improvements added during the last Sprint and determine if they were helpful or harmful to the team’s ability to meet Sprint Goals. Only beneficial process should be kept, any process which is neutral or negative should be removed. It should also be noted that the Scrum Team may make improvements to their process at any time, the Sprint Retrospective acts as a recurring opportunity to make the process easier. Ultimately, running meaningful Sprint Retrospectives is hard, it’ll be yet another topic that we explore in depth in a later post.

Conclusion

I hope our “brief” discussion on the Scrum framework has been helpful for both your and your team’s understanding. Scrum is not going to be the silver bullet for your team’s performance, however, it will most likely help your team to understand how to improve and be able to implement their found understanding. From my personal experience attempting to leapfrog the learning process will eventually cause you to stagnate without a way to unstick the process. Whereas, if you are constantly inspecting and adapting your process and only trying to be slightly better than you were in the last iteration you’ll learn a lot more about both your process and how to improve it.

If you have any questions please feel free to reach out to me through the comments or through the contact form.

Happy Scrumming!

Further Reading