Read ONLINE

How does all this happen? Well, In Scrum, work is done in Sprints. A Sprint is a fixed duration with a specific start time and end time. A Sprint cannot be longer than 30 days. Once a team decides on a Sprint length, all Sprints follow the same length so that the team works on a regular cadence.

The Sprint starts with Sprint Planning where the team plans out their work for this Sprint. In Sprint planning, they establish a Sprint Goal, pull the high-priority items from the top of the Product Backlog that will help accomplish the Sprint Goal, and then task out the activities that they have to do in order to build and develop these Product Backlog Items into a working Product Increment. The Sprint Goal, the Product Backlog Items, and the tasks are known as the Sprint Backlog, or the team’s plan to accomplish the work. From this point on, the team is focused on the Sprint Backlog and collaborates together to complete these items as effectively as possible. Every day the Developers plan their day in what is called a Daily Scrum where they inspect their progress toward the Sprint Goal and adjust the Sprint Backlog accordingly. This continues until the end of the Sprint where the Developers package up what they completed into a Product Increment. The Product Increment is the output of every Sprint. It is a quality, working, useful, and valuable increment that includes all the previously built increments in addition to what was just built in this Sprint. The Product Increment should be at a level of quality as per the team’s agreed-upon Definition of Done.

At the end of each Sprint, the team has a Sprint Review where they collaborate with the Stakeholders and users to get feedback on what they built and what to build next. “Here’s what you asked us to build, and here is what we built. Is this correct? Is this what you were expecting? Is this valuable? Are we on the right track? Here’s what we are about to work on next? Is this still the most valuable thing we can be working on? Based on the feedback, the Product Owner adjusts the Product Backlog accordingly. This ensures that for each Sprint, the team is always working on the most valuable items and are regularly delivering value to the stakeholder in an iterative and incremental fashion.

Next, the team has a Sprint Retrospective to inspect how they are working as a team and see if they can improve. The Sprint Review is about inspecting and adapting the Product, while the Sprint Retrospective is about inspecting and adapting the process of building the Product. Any action items that come out of the Sprint Retrospective get added to the next Sprint Backlog as tasks for the team to work on.

Throughout the Sprint, the team is actively doing Product Backlog Refinement where they refine, clarify, research, estimate, split, and prep the Product Backlog Items so that the items at the top of the Product Backlog are ready to be worked on. There are no breaks in between Sprints. When one Sprint ends, the next one starts, so the product backlog needs to always be prepped with actionable items for future Sprints.

Finally, there is the Scrum Master, who is the team’s leader providing servant Leadership to support the Developers, the Product Owner, and the organization as a whole, ensuring that everyone is working together effectively and making forward progress toward their goals. The Developers, the Product Owner, and the Scrum Master are known as the Scrum team.

This is the Scrum Framework as defined by it’s

5 events: The Sprint, and within the Sprint, Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective

It’s 3 Artifacts: The Product Backlog, Sprint Backlog, and Product Increment along with the 3 commitments of the Product Goal, Sprint Goal, and Definition of Done.

And finally, it’s 3 accountabilities of Product Owner, Developers, and Scrum Master.

The 3 artifacts in Scrum are:

• Product Backlog, an order list of Product Backlog Items that emerges from the Product Goal and includes hypotheses, requirements, features, enhancements, etc.

• Sprint Backlog, the team’s plan to accomplish the work for the Sprint. It includes a Sprint Goal, a cohesive set of Product Backlog Items pulled from the Product Backlog that help accomplish the Sprint Goal, and a list of tasks needed to complete the Product Backlog Items and accomplish the Sprint Goal.

• Product Increment, the output of every Sprint. It is a useful, valuable, usable, and working increment that is at a level of quality as per the team’s Definition of Done. It includes all the previously built increments in addition to what was just built in this Sprint.

• The Product Goal, Sprint Goal, and Definition of Done are referred to as commitments in Scrum. The Scrum team commits to delivering a Product Increment that meets the Sprint Goal, is at a level of quality as per the team’s Definition of Done, and gets them one step closer to the Product Goal.

The 5 events in Scrum are:

• The Sprint, a fixed duration with a specific start time and a specific end time. A Sprint is less than 30 days. Once a Scrum team decides on the length of the Sprint, every Sprint will be the same length from Sprint to Sprint as the team establishes a regular cadence and work rhythm. Instead of changing the size of the Sprint to fit the upcoming work, the team breaks down the work into more manageable pieces to fit within the Sprint. The Sprint is a container event for all the other Sprint events of Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective.

• Sprint Planning, a planning event at the beginning of each Sprint to inspect the Product Backlog, the progress made toward the Product Goal based on the latest Product Increment, and adapt or create the Sprint Backlog and the team’s plan to accomplish the work for the current Sprint. This includes establishing a Sprint Goal, pulling a cohesive set of Product Backlog Items from the Product Backlog that will help accomplish the Sprint Goal, and then task out the work needed to complete each pulled Product Backlog Item.

• Daily Scrum, a daily planning event by the Developers to inspect their work and the progress they are making toward the Sprint Goal, and then plan their day accordingly by adapting, adjusting, and updating the Sprint plan known as the Sprint Backlog.

• Sprint Review, a collaborative working session with the stakeholders towards the end of each Sprint to determine the progress made towards the Product Goal by inspecting the Product Increment, getting feedback on it, and then adapting and updating the Product Backlog accordingly, thus ensuring the Scrum team is always working on the most valuable items.

• Sprint Retrospective, a reflection event at the end of each Sprint for the Scrum team to inspect their team dynamics, relationships, tools, and processes and then come up with a continuous improvement plan for the team and organization to adapt and become more effective.

And that’s the Scrum Framework as defined by

• It’s 3 accountabilities of Product Owner, Developers, and Scrum Master.

• It’s 3 artifacts: The Product Backlog, Sprint Backlog, and Product Increment along with the 3 commitments of the Product Goal, Sprint Goal, and Definition of Done.

• It’s 5 events: The Sprint, and within the Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective.

Developers work on small Scrum teams to maintain good interactions and communications. Too few team members and they won’t have all the necessary skills to deliver a Product Increment. Too many team members and they won’t have good team interactions, collaboration, and communication.

Developers are also self-organizing. Developers decide how to do the work, how long it’s going to take, how much of it they can do in each Sprint, and who is going to work on what. Developers determine how best to accomplish the Sprint Goal, task out their work, estimate it, and assign themselves work. Developers are the ones closest to the work and thus know best how to accomplish it.

Developers in Scrum are stable and long-lived. Team members don’t get swapped in and out from Sprint to Sprint. The team members stay together for an extended period of time so that they grow together and develop strong team dynamics, build trust, and become high-performing.

Everyone who builds the product increment is referred to as a Developer. Developer does not equal programmer in Scrum. There are no testers, no analysts, no architects, and no programmers. It’s just Developers with cross-functional skills like testing, analysis, architecture, programming, etc. There are no sub-teams of Developers. Again, it’s just Developers to encourage the idea that they are all in this together. It’s not about the individual and finishing individual tasks. It’s about the team with mutual accountability for accomplishing the Sprint Goal and delivering a quality working Product Increment at the end of each Sprint. What matters is accomplishing goals and delivering a quality Product Increment, and everyone is accountable for that irrespective of their primary skill set.

The Product Owner is accountable for delivering a valuable Product Increment. The Product Owner does that by ensuring that Developers are working on the most valuable items. The Product Owner is 1 person and not a committee. The organization empowers the Product Owner to listen to the market, the customers, the buyers, the users, the developers, and the stakeholders and then make the best decision possible on what to work on next. The Product Owner is the decision maker and collaborates and engages with the stakeholders and Developers to determine the product strategy and business model, provide strategic direction, create product vision, goals, and roadmap, research the market and users to discover opportunities, needs and pain points, analyze the market and competition, determines value propositions, manage, order, prioritize, and refine the Product Backlog, and clarify the work for the developers.

The Scrum Master is accountable for the effectiveness of the Scrum team and the organization. The Scrum Master is the team’s leader providing servant leadership to help the Product Owner, Developers, and the organization make forward progress toward their goals. The Scrum Master educates the team on Scrum, helps establish empiricism, plans and advises on Scrum implementations, leads, trains, and coaches the organization on Scrum adoption, helps remove impediments, empowers the team, enables cooperation and collaboration, increases visibility and transparency, and facilitates as requested keeping events effective, productive, and within the timebox.

The Scrum Master coaches the Team in self-management and cross-functionality. Once a team is empowered to make how decisions (Developers) and is empowered to make what decisions (Product Owner), the Scrum team of about 10 people, can become a self-managing Scrum team that collaborates directly with stakeholders and users to deliver quality valuable Product Increments that meets their needs.

And that’s what a Scrum team is all about. A small self-managing team that can just run with things and regularly delivers a valuable, quality, working product while actively collaborating with the customer. This is very different from the hierarchical approach of most organizations where decisions get made at the top and then trickle down and down from one person to the next to the next until it gets to the team building the product and those team members usually end up having zero interactions with the users of the product.

It’s the Scrum Master who is championing and bringing about this change in how organizations approach work and how organizations and teams are structured, in order to foster high-performing, highly effective self-managing teams that continuously deliver value.

And that’s the Scrum team. A cross-functional, self-managing team that regularly collaborates with the stakeholders and users to build valuable quality products. The team has 3 accountabilities, Product Owner for value, Developers for quality, and Scrum Master for effectiveness.

At any point in time, if you take a picture of the Product Backlog, it is going to look like this. Towards the top, the Product Backlog consists of fine-grained Product Backlog Items. These are items that have been reviewed, researched, clarified, estimated, and broken down into very small items that are considered “Ready” for the next Sprint and can get pulled into the Sprint Backlog and tasked out in Sprint Planning.

Towards the middle, the Product Backlog Items are less refined, a bit larger, and require clarification before being worked on.

Towards the bottom, the Product Backlog Items are large concepts or ideas that are vague, not yet well thought out, and require a lot of clarification before being worked on.

The Product Backlog will always look like this, with mostly fine-grained items towards the top and coarse-grained items towards the bottom. It will look like this on day 5, on day 25, on day 50, and on day 250. Why? Because as the top items that are “Ready” to be worked on get pulled into the Sprint Backlog, the items below them, move up and get broken down and clarified, and the items below them also move up and get broken down and clarified and so forth, doing this just in time and at the right level of granularity. This happens in Product Backlog Refinement and is referred to as progressive elaboration where the team clarifies the upcoming work as it gets closer and closer to working on it.

This is very different from the traditional “waterfall” development with big upfront plans based on detailed upfront requirements and designs. In Scrum, with empiricism, knowledge of what to do next is gained from building and developing, and that knowledge informs the requirements and designs and allows for continuous feedback and adjustments.

Product Backlog Refinement is an ongoing activity that occurs throughout the Sprint. It is not a time-boxed event. Just as the team dedicates time during the Sprint to build a Product Increment, the team also dedicates time to do ongoing Product Backlog Refinement. Refinement involves the Scrum team, with the key conversation happening directly between the Product Owner and Developers.

The Product Owner decides where a new Product Backlog Item might go, whether it goes towards the top, middle, or bottom based on its relevance and importance, always keeping the Product Goal in mind.

At any point in time, the Product Owner might drop an item deemed no longer important or necessary.

Throughout, the Product Owner regularly re-orders the Product Backlog based on the latest information and knowledge gained.

The Developers seek clarification, research, estimate, identify risks, and break items down into more manageable chunks of work so that by the time the items reach the top of the Product Backlog, they are “Ready” to be worked on.

And that’s Product Backlog Refinement, an ongoing activity that the Scrum team does throughout the Sprint to add, remove, reorder, clarify, research, estimate, split, or merge Product Backlog items to progressively elaborate on them so that the items towards the top of the Product Backlog are always ready for the next Sprint. Because when one Sprint ends, the next one starts. There are no breaks in between to figure out what to work on next. It’s the Ready items on the top of the Product Backlog. 

In Sprint Planning the team covers 3 topics:

The first topic is about the Why? That is, why is the upcoming Sprint important? What is the Goal of this Sprint? Each Sprint has a Sprint Goal that creates focus for the team and results in a Product Increment that gets the team one step closer to the Product Goal.

The second topic is about the What? Now that the Sprint Goal is clear, the team figures out what cohesive set of Product Backlog Items will help accomplish the Sprint Goal which results in a Product Increment that gets the team one step closer to the Product Goal.

The third topic is about the How? For each Product Backlog Item, the team tasks out the activities needed to complete the item so that the team can accomplish the Sprint Goal which results in a Product Increment that gets the team one step closer to the Product Goal.

The Sprint Goal, the selected Product Backlog Items, and the tasks become the Sprint Backlog. This is the team’s plan to accomplish the work and to deliver on the Sprint Goal.

Parts 1 and 2 are led by the Product Owner with the Developers seeking clarification and providing input. Part 3 is led by the Developers with the Product Owner readily available to answer any remaining questions.

Developers must account for the work needed to accomplish the Sprint Goal as well as all other work that typically happens during the Sprint, like Product Backlog Refinement, continuous improvement initiatives, retrospective action items, technical debt, holidays, vacations, training, etc. In addition, Developers need to account for impediments and distractions like bugs, production issues, all hands-meeting, supporting other teams, and so forth. Developers consider their historical capacity and then assess whether the work is feasible. If not, the Developers negotiate with the Product Owner to reduce the scope while still achieving the goal. Finally, the Developers make a commitment to each other to accomplish the Sprint Goal.

And that’s Sprint Planning, the 1st event of every Sprint in Scrum. It’s a timeboxed event for the Scrum team to create the plan for accomplishing the work taking into account what still needs to be built based on the Product Backlog, what has already been built based on the Product Increment, the direction the team is heading in based on the Product Goal, and the team’s historical performance and current capacity. It’s 3 topics of why? what? And how? to create a Sprint Backlog that consists of the Sprint Goal, the Product Backlog Items, and the tasks that will help deliver on the Sprint Goal that will result in a Product Increment that gets them closer to the overall Product Goal. 

The Daily Scrum occurs every day at the same time and is timeboxed to 15 minutes per day. Traditionally, each Developer talks about what they did yesterday to help accomplish the Sprint goal, what they plan to do today to help accomplish the Sprint goal, and what’s in the way that might prevent them from accomplishing the Spring goal. This approach helped the team focus and finish the event within the timebox. However, this format morphed the Daily Scrum into a status meeting instead of its intended purpose.

The Daily Scrum is not a status meeting. Neither the Product Owner nor the Scrum Master is required at the Daily Scrum. It’s a daily planning event for the Developers by the Developers to plan their day and figure out how they are going to collaborate together and support each other to do the necessary work to deliver on the Sprint Goal and produce a Product Increment.

The Daily Scrum is also not the place to raise impediments. Impediments are raised immediately when they arise. The Daily Scrum is the place to make sure that all impediments or blockers are visible and transparent and that someone is actively working on resolving them.

The Daily Scrum is also not the place for deep-dive discussions. Whoever needs to stick around to clarify an issue or help can do so in ad-hoc meetings set up right after the Daily Scrum.

And that’s the Daily Scrum. A timeboxed daily event by the Developers and for the Developers to plan their day and adjust their Sprint Backlog based on the progress they are making towards the Sprint Goal in order to successfully deliver a Product Increment at the end of the Sprint.

In the Sprint Review the team shares with the stakeholders the Sprint goal and the Product Backlog Items the team worked on to deliver on the Sprint Goal and produce the Product Increment. The team might demo the Product Increment or have the stakeholders use it to verify that what they built meets their expectations, that they are on the right track, and that the Increment is useful and valuable. The team verifies that the next items in the Product Backlog are still the most important items to work on or whether they should pivot and work on something else instead. Based on this feedback, the Product Owner adjusts and adapts the Product Backlog accordingly to meet any new opportunities or requirements identified and therefore ensuring that the Scrum team is always working on the most valuable items.

The Sprint Review happens towards the end of the Sprint, involves the entire Scrum team collaborating with the stakeholders and users, and is timeboxed to 4 hours for a 4-week Sprint or 2 hours for a 2-week Sprint, and so on.

And that’s the Sprint Review. A timeboxed event that occurs towards the end of the Sprint for the Scrum team to collaborate with the stakeholders and inspect the Product Increment and the progress being made toward the Product Goal and to adapt the Product Backlog accordingly.

In the Sprint Retrospective, the team might consider their team dynamics, relationships, processes, tools, or their Definition of Done, and then come up with action items to take on to improve. There are many types of retrospectives, the most basic is referred to as pluses and deltas where the team looks at what went well and what can be improved and then takes on improvement action items accordingly. The action items from the retrospective go into the next Sprint backlog as tasks for the team to work on to become more effective. This means that in the next Sprint, the team needs to allocate some time for continuous improvement initiatives that came out of the retrospective.

The Sprint Retrospective is the last event of the Sprint and is timeboxed to 3 hours for a 4-week Sprint and 1.5 hours for a 2-week Sprint and so on.

And that’s the Sprint Retrospective. A timeboxed event that occurs at the very end of the Sprint for the Scrum team to inspect their processes and adapt to continuously improve and become a more effective team and organization.

The Product Increment is built iteratively and incrementally which means it includes all prior increments plus what was just built. This means the team continuously delivers products from Sprint to Sprint and regularly gets feedback ensuring the team is always working on the most valuable items. The Product Increment is a useful, valuable, and usable Product Increment and must be at a level of quality as per the Team’s Definition of Done.

The Definition of Done is the team’s auditable quality checklist. It is established as part of the team’s working agreement at the very beginning and then gets strengthened over time. The Definition of Done is not established in Sprint Planning because it does not change from Product Backlog Item to Product Backlog Item as it has more to do with how the team operates to ensure quality and less to do with the actual requirement they are building. Over time, the team improves its processes via regular retrospectives and updates its Definition of Done accordingly.

It is important to note that the team does not need to wait until the end of the Sprint to deliver the increment and can deliver multiple increments within the Sprint as long as the increment is a quality increment that meets the team’s Definition of Done.

And that’s the Product Increment, a working, useful, valuable, increment that’s delivered every Sprint, includes all previous Product Increments, and is at a level of quality as defined by the team’s Definition of Done. 

Commitment: In Scrum, the team commits to each other, not to other people, but to each other, on supporting each other to deliver on the Sprint Goal and Product Goal.

Focus: In Scrum, the team focuses on accomplishing the Sprint goal and minimizes any distractions that might prevent them from accomplishing the Sprint Goal. The team works on 1 Sprint goal at a time.

Openness: In Scrum, the team is open to new ways of working. They make sure that the work is visible and they are transparent about any challenges they are facing that will prevent them from accomplishing the Sprint Goal.

Respect: In Scrum, the team consists of members with various skill sets. The team respects each team member based on their capabilities and support and trusts each other to deliver on the Sprint Goal.

Courage: In Scrum, the team has the courage to work through tough problems, speak up when things are not going well, and then do the right thing.  Without the courage to speak up, the team and the organization will not improve.

And those are the 5 Scrum values of commitment, focus, openness, respect, and courage. The way the Scrum team behaves, approaches work, and tackles impediments should be guided by these values.  The decisions that they make and the actions that they take should reinforce these values, not diminish them. When these values are embodied by the scrum team and the people they work with, true empiricism comes to life. 

Scrum is founded on Lean thinking and empiricism. Lean thinking reduces waste and focuses on essentials. Empiricism asserts that knowledge comes from experiences. That is, do the work, see how it went, and then decide what to do next based on what was just learned. The 3 pillars of empiricism are transparency, inspection, and adaptation. Transparency into the work is necessary in order for the team to properly inspect the work and adapt accordingly. Regular timeouts are also necessary for the team to stop what they are doing, pause, look back at what just happened, and then decide how to move forward. In Scrum, the Product Increment provides transparency into what has been built so far. The Product Backlog provides transparency into what still needs to be built. The Sprint Backlog provides transparency into what is currently being built. The 4 events of Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective within the containing Sprint event provide the opportunity for the team to regularly inspect and adapt based on the transparency provided by the updated artifacts.

The events in Scrum are time-boxed. Once the end of the time-box is reached, the event ends and the team moves on (irrespective of whether the work to be done is completed or not). Based on the size of the Sprint, each event has a recommended maximum time limit. For a 1-week Sprint, Sprint Planning is timeboxed to 2 hours, Daily Scrum to 15 min/day, Sprint Review to 1 hour, and Sprint Retrospective to 45 min. The timebox limits increase proportionally for longer Sprints.

When the team has a short period of time to do something, the team prioritizes and figures out what’s most important to work on right now. The team breaks down large and complex work to fit in the timebox. The team focuses on finishing and delivering the work within the timebox. The team gets the opportunity to get feedback at the end of each timebox. With frequent feedback, the team adjusts and continuously improves to become more effective. These are all benefits of timeboxing.

Scrum is just a framework, which means it is purposely incomplete. It is not a prescriptive methodology with detailed instructions. Instead, it is just a lightweight guide that provides guard rails to keep teams heading in the right direction and prevents them from falling off. The Scrum rules, team structure, way of working, accountabilities, artifacts, and events, are set up to keep the team on track by regularly inspecting and adapting. If Scrum is only partially implemented, the guard rails might crack, and the team will not realize the benefits that Scrum delivers.

Based on a team’s context, organization, type of product being built, unique challenges, and their latest observations and learnings, a team may employ additional practices and techniques within the framework. What works for 1 team in 1 organization might not work for another team in another organization. It’s all contextual and there is no 1 best way of using Scrum. For those reasons, Scrum is said to be lightweight and simple to understand, yet difficult to master. Lightweight and simple to understand because the Scrum Guide is less than 20 pages and just lays out Scrum theory along with the Scrum accountabilities, artifacts, and events. It’s difficult to master because Scrum requires a change in how organizations and teams are traditionally structured and how they approach work, and many are resistant to change and find the necessary changes too disruptive.

And that’s Scrum. A framework used for solving complex adaptive problems. There is no hiding in Scrum. A team has a short period of time to deliver value. If they can great! If they cannot, it will be obvious and transparent as to why. Scrum on its own, will not solve the team’s problems, but instead, Scrum shines a bright light on the team and organizational impediments. It’s up to the team and the organization to decide what to do about those impediments and how to address them for continued success.

Back in February 2001, at the lodge in Snowbird Utah, 17 thought leaders from the software industry got together to discuss the state of software development and compare various lightweight frameworks that popped up in the late 90s because of dissatisfaction with the traditional waterfall approach to building products.

The participants shared and learned about each other’s frameworks, including Scrum, eXtereme Programming (XP), Feature Driven Development (FDD), Adaptive Software Development, Crystal, Dynamic Systems Development Method (DSDM), and others, and summarized the essence of their work by publishing the Manifesto for Agile Software Development consisting of 4 value statements along with 12 principles.

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and Interactions over Processes and Tools

Working Software over Comprehensive Documentation

Customer Collaboration over Contract Negotiations

Responding to Change over Following a Plan

That is, while there is value in the items on the right, we value the items on the left more.

The 12 principles behind the Manifesto

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity--the art of maximizing the amount of work not done--is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Scrum’s influence on crafting these values and principles is clear with its focus on team composition, self-organization, regular communication and collaboration between team members and customers, working in Sprints to maintain a sustainable pace, frequently delivering a working valuable product at the end of each Sprint, focusing on customer satisfaction and customer value, regularly adjusting to new requirements, and continuously inspecting and adapting to become more effective.

Scrum is a framework that organizations and teams can use to become Agile and live by these values and principles. Scrum is never the goal. It’s just a tool to help you deliver value.

•  The Manifesto for Agile Software Development @ https://agilemanifesto.org/

• Principles Behind the Agile Manifesto @ https://agilemanifesto.org/principles.html

• Behind the Scenes Look at The Writing of the Agile Manifesto @ https://www.kaizenko.com/a-behind-the-scenes-look-at-the-writing-of-the-agile-manifesto/

•  The Scrum Guide @ https://www.kaizenko.com/the-scrum-guide/

• The Scrum Guide History @ https://www.kaizenko.com/the-scrum-guide-history/

• The Scrum Canvas @ https://www.kaizenko.com/tag/templates/