Enhanced Scrum Guide

Good practices to reach hyper efficiency with Scrum. The Enhanced Scrum Guide adds tools and practices to the official Scrum Guide.

This blog relates to the Scrum Guide, which is still, as of early 2016, the 2013 version. Its purpose is to complete the official guide with the essential know-how and to explain some practical steps to start Scruming in an efficient way. To make clear what is from the Scrum guide and what is my addition, I’ve written in different colors. I have not changed anything to the parts belonging to the official guide. Let’s call the result an “Enhanced Scrum Guide”.

Jeff Sutherland said that Ken Schwaber (together the co-creators of Scrum) convinced him to not include tools in the framework, to keep it lightweight. Tools evolve; with continuous improvement new practices replace older ones, or improve them. There is no best practices in agile, as your situation and context will define which ones you will use, and how. That makes agile in general and the Scrum framework in particular more difficult to master than traditional, bigger prescriptive methodologies, as you can’t just learn and apply from the book: agile requires you to think, try, check and adapt. And that cycle concerns both the products you develop and the way you develop them.

However, there is a set of useful tools and practices that helps A LOT to get the best of agile in general, and Scrum in particular. So if you are new to Scrum, or if you want to update your knowledge, you will find in this Enhanced Scrum Guide a summary of the tools and good practices that use some of the best Scrum teams. Although, please note that no practice or tool should be opposed to innovation: if you think you have discovered a solution to do something in a better way, do it, try it! If it proves to be better when you apply it, then share it with the agile community! Scrum is based on empirical improvements, so again: observe and think, try, check, adapt, and repeat until you reach a satisfying result.

Scrum has been firstly used for software development (google, apple, Microsoft, SAP, Salesforce, Spotify…), but has now expanded to some administrations, to schools with great success, and to industry where it has led to impressive productivity rise, ask John Deere! Yet as I have an IT background, some of the tools and practices here are more IT centric. So if you are not part of an IT team, just do your best to understand the purpose of those practices and tools, and how they could be adapted to your own environment.

The guide starts here.


Purpose of the Scrum Guide

Scrum is a framework for developing and sustaining complex products. This Guide contains the definition of Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together. Ken Schwaber and Jeff Sutherland developed Scrum; the Scrum Guide is written and provided by them. Together, they stand behind the Scrum Guide.

Definition of Scrum

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

Scrum is:

    • Lightweight
    • Simple to understand
    • Difficult to master

(Have you read the pmbok -589 pages- or prince2 -420 pages- manuals? The original Scrum Guide explains the whole framework in just 16 pages, that’s already agile!)

Scrum is a process framework that has been used to manage complex product development since the early 1990s. Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and development practices so that you can improve.

The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage.

The rules of Scrum bind together the events, roles, and artifacts, governing the relationships and interaction between them. The rules of Scrum are described throughout the body of this document.

Specific tactics for using the Scrum framework vary and are described elsewhere.

-> In this Enhanced Scrum Guide for example!

Scrum Theory

Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk. Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.


Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.

For example:

  • A common language referring to the process must be shared by all participants; and,
  • Those performing the work and those accepting the work product must share a common definition of “Done”


Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances. Their inspection should not be so frequent that inspection gets in the way of the work. Inspections are most beneficial when diligently performed by skilled inspectors at the point of work.


If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation.

Scrum prescribes four formal events for inspection and adaptation, as described in the Scrum Events section of this document:

  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Sprint Retrospective


As I will give explanations early on using some particular vocabulary, let me sum up Scrum iteration principle and its constituents, so that you understand what I am talking about. The guide will later define all of that more precisely.

Whether you want to create a new software or to build a swimming pool in your garden, there are many steps and tasks you know you have to do. In Scrum, this list of tasks is called the Product Backlog. There is one person in charge of the Product Backlog, this person is called the Product Owner. Whether to define the color of the swimming pool or the functionalities of a software, the Product Owner is the one who has authority over the content of the Product Backlog.

The group of people who will carry out those tasks is called the Development Team. In Scrum the work is organized by periods of time of 1 to 4 weeks –when you choose a length, stick to it until the product is finished-, called Sprints. At the beginning of a Sprint, your team sets up a Sprint Planning meeting to select which parts of the Product Backlog it will have time to complete during that Sprint.

The selected items then constitute the Sprint Backlog. Only items that are READY can be included in a Sprint Backlog. To be READY means that the tasks to be done have been well defined and each team member fully understands them.

During the Sprint the team works on the Sprint Backlog tasks to complete them by the end of the Sprint.

At the end of the Sprint, in a Sprint Review meeting, the team will present to the Product Owner and other stakeholders the work it has achieved during that Sprint. The team presents only the fully operational work achieved (we say DONE in scrum), what is not fully finished (not DONE) is not presented. There is a list of criteria defining when a task is DONE. This list is your Definition of Done. The tasks that were not fully DONE are sent back to the Product Backlog list, to be selected in a future Sprint.

Right after the Sprint Review meeting, the team gets together for a Sprint Retrospective meeting, in which it considers what went well and not so well during the Sprint, and considers what it could change to work better and faster. There is always something to improve. Always.

Then the next Sprint begins, with a Sprint Planning meeting.

That is the Scrum framework in few words. Now, few more words about the main tools and concepts I am to present in this guide. I here wish to repeat that those tools are often used in agile development, but they are neither mandatory nor the only ones you can use while facing a particular situation.

User actions are often called stories in agile. Stories are usually described in the format “as a <type of user>, I want to <action>, so that <desired outcome>”. The chain of actions the users follow from the beginning to the end (for example from arriving on your website to buying a product) is called a story map. We call it this way, as when you describe how the user uses your product, you tell a story.

As you can imagine, stories are like Russian dolls: there are various layers, depending on how detailed you need them to be. High level stories are referred as Epic stories, or sometimes as features. If we consider the creation of an online shop specialized in computer components, we could have Epics like: “as a private user, I want to buy a hardware product so that I can upgrade my computer”. That is a high level story, so it is an Epic story. When zooming in, we will detail it further, creating smaller stories (called, well, stories, at this level of detail), like “as a private user, I want to be able to add a product to my basket so that I can buy it”. This is one of many actions allowing the completion of the Epic story.

Telling stories enables everyone in the team to better understand what and why we build, it allows to reach a common understanding of the product requirements. The development team will then decide how to implement/code the stories, defining a group of required technical tasks to complete each story.

The sum of your stories and their particular constraints constitutes your product/project requirements. We will see later how to write them correctly, so that it also becomes a living documentation of your work, especially for its maintenance.

The Scrum Team

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.

Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available.

For transparency, it is recommended to display basic information about the team on your office space door/access so that passers by know what’s going on there: what product is the team working on, what is the current Sprint goal, who’s the Scrum Master, who’s the Product Owner, who are the development team members, when and where are the regular Scrum meetings.

The Product Owner

The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

  • Clearly expressing Product Backlog items;
  • Ordering the items in the Product Backlog to best achieve goals and missions;
  • Optimizing the value of the work the Development Team performs;
  • Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
  • Ensuring the Development Team understands items in the Product Backlog to the level needed.

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.

For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.

Add features because they have high value for your product’s users, not because you have the time and resources to add them

The value delivered per quantity of work is the main indicator of a PO (Product Owner) efficiency. A good PO is not the one whose team is able to include a maximum of features before a given deadline, it is the one who knows to stop his team’s work when all valuable features have been implemented, leaving out those with low value. Remember: 80% of a product value is contained in just 20% of its features.

Should the PO be on just one team or many teams? 

Well, you will find different answers about it, depending on what scaled Scrum framework you look at (scaled Scrum frameworks propose solutions to adapt Scrum to a large number of Scrum teams, or even to an entire company’s organization). When multiple teams work on a common project, some recommend one PO per team with a chief PO over them to synchronize the different teams’ backlogs. This is used for example by most of the teams at Spotify, where only a few teams share a single product backlog. However, in the Nexus scaled Scrum framework (and I will refer to this one as it is the one proposed at the end of 2015 by Scrum co-creator Ken Schwaber), you only have one product backlog, and so just one PO.

The Development Team

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment.

Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.

Development Teams have the following characteristics:

  • They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
  • Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment;
  • Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;
  • Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule; and,
  • Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

Can team members change from one Sprint to the other?

Yes, depending on the type of work and skills required for the Sprint, some members can leave and others join. However, you should expect some loss of efficiency until the new member(s) is (are) fully operational and have a clear understanding of the project. Also, a big bonus in velocity (team’s working speed) comes from increased team cohesion, so you should favor keeping the core team united to allow for this continuous improvement. Team stability is a proven factor in achieving hyper efficiency.

Can team members be part-time members?

Better not. Being part-time means switching activities, and multitasking is known to be not efficient, as the person loses time, focus and energy when switching from one task to another. Your cumulated work on separated tasks will always be less than what you could do if you would focus on a single task. That is also the principle of limiting WIPs (work in progress), a base for kanban and also an essential good practice for efficient Scrum teams. The second problem of multitasking is that if the team needs you and you are not available, the result is a loss of time and efficiency for the team.

Maximize team members’ interactions

Interactions between the team members are essential to increase velocity (team’s speed), and the best way to promote interaction is to have the team collocated. Not just in one building, but in the same room, being able to interact without being disturbed by non team persons (interruptions greatly reduce a team velocity, we will look soon at how to deal with it).

Not being collocated also means you have to use a virtual Product Backlog (the list of everything you want to create for your product) and virtual Sprint Board (a view of everything you plan to do for the product in the actual Sprint). At Scruminc.com (Scrum co-creator Jeff Sutherland’s company) they use Pivotal Tracker, a lightweight solution, but the market leader is Jira. It is also necessary to use all the tools that will best help facilitate distant communication and interaction. Google hangout, Skype… Check Agile Cockpit also, it is a solution defined specifically for distributed agile teams, it includes videos feeds and recordings of your daily Scrums. Oh, and when you have a collocated team but one member is stuck at home, some solutions have started to emerge to yet “be” at work! 

Careful: being distributed amplifies existing problems. So, to be successful, being not collocated requires dedicated and skilled people used to work with good agile practices.

Code Extreme!

Extreme Programming recommends many efficient practices, such as pair programming and Test Driven Development (TDD). With TDD the developers don’t write the code first, but the tests. Then, when the tests are written, they write the minimum code to successfully pass those tests. This puts an emphasis on the tests, and so on bug reduction. What it costs as time to write the tests is partly deduced from the design analysis, as the coder, while defining those tests, also thinks about the code design. And coding just what is necessary to pass the test prevents gold platting, which is when coders do some extra work that they deem pertinent but that has not been agreed upon previously by the team in general and the product owner in particular. Gold platting more than often leads to more code complexity, poor UI (User Interface) and UX (User Experience), and technical debt (non optimal code or code design that will require regular maintenance and attention until it is corrected) through necessary maintenance of a low, or even negative, value item.

What about the test team then? With Scrum the tests are done along the development during the sprint, and most of them are automated, as manual tests are costly, slow, and humans are known to sometimes make mistakes. So if your company has a dedicated test team, split it and bring one tester into each Scrum team, so that he helps in defining the automated tests.

TDD evolved to a new level when Dan North defined BDD (Behavior Driven Development), in which  test scenarios are written with domain language (that is, the vocabulary used in the field of application, whether medical, industrial, educational…), and are therefore understandable by non developer people, as often the Product Owners and stakeholders (group of people having a direct interest and/or influence on the project/product) know not much about code. The scenarios are written with the “Given When Then” (GWT) structure, here is an example for two scenarios related to an ATM software:

+Scenario 1: Account is in credit+

Given the account is in credit

And the card is valid

And the dispenser contains cash

When the customer requests cash

Then ensure the account is debited

And ensure cash is dispensed

And ensure the card is returned

+Scenario 2: Account is overdrawn past the overdraft limit+

Given the account is overdrawn

And the card is valid

When the customer requests cash

Then ensure a rejection message is displayed

And ensure cash is not dispensed

And ensure the card is returned

It gives a clear understanding of the situation, the action and its expected result. This is understandable by everyone, and it eases the developers to create that software component and its automated tests. With the appropriate BDD tools, and among them the famous Cucumber, the PO or a Business Analyst can write those functional scenarios, and the development team can transform them quickly into automated tests. This is a powerful instrument to quicken test writing, and it also helps considerably to share a common understanding of what the product should do, and how.

Pay attention, when writing acceptance tests, to focus on the user perspective. Acceptance tests  are functional and not technical, they should be used to detail a specific user situation, user action and functional result, not a technical process. It specifies what happens, not how. The how is the domain and choice of the dev team, business specifications by BDD focus on the user perceived results, not the technical process behind. The how might evolve over time, with new technologies or evolving code design or architecture, while the functionalities might not change, and so their acceptance criteria and corresponding tests/scenarios will stay the same and still be valid whatever the how.

Agile development includes just the necessary documentation

It is a common mistake to believe that agile means no documentation. It is truly wrong. Agile development requires the necessary quantity of documentation to allow for code maintenance. When you use Specification by Example, such as BDD scenarios, those scenarios detail the situation, action and output of a feature. The sum of all your features and their corresponding scenarios then become your living documentation. If your features/stories with their acceptance scenarios are kept in a ordered, easily understandable, accessible way, then it is really possible that this living documentation will be your main, and maybe sole, documentation for code maintenance.When you change a feature you first update its acceptance scenarios, this way updating your acceptance tests and your living documentation in the same time.

An example of a feature, taken from the Cucumber Book:

Feature: Sign up
Sign up should be quick and friendly.
Scenario: Successful sign up
New users should get a confirmation email and be greeted personally by the site once signed in.
Given I have chosen to sign up
When I sign up with valid details
Then I should receive a confirmation email
And I should see a personalized greeting message
Scenario: Duplicate email
Where someone tries to create an account for an email address that already exists.
Given I have chosen to sign up
But I enter an email address that has already registered
Then I should be told that the email is already registered
And I should be offered the option to recover my password

Another example, with a user story’s acceptance scenarios, from wikipedia’s BDD article:

Story: Returns go to stock

In order to keep track of stock
As a store owner
I want to add items back to stock when they’re returned.

Scenario 1: Refunded items should be returned to stock
Given that a customer previously bought a black sweater from me
And I have three black sweaters in stock.
When he returns the black sweater for a refund
Then I should have four black sweaters in stock.

Scenario 2: Replaced items should be returned to stock
Given that a customer previously bought a blue garment from me
And I have two blue garments in stock
And three black garments in stock.
When he returns the blue garment for a replacement in black
Then I should have three blue garments in stock
And two black garments in stock.

Empower your tests!

Include the necessary tests for initial validation of your actual piece of work, and then define those among them that will be added to the recurring list of regression tests: performance tests, accessibility tests, security tests, UI tests with click maps and chain events simulations… It takes time originally, but you gain so much in quality, reliability, and the team gets super confident about its work, because so many risks are dealt with, baked in the development process! Good teams usually prevent or correct 90%+ of the bugs with those good practices. So imagine the time and money you save when you don’t have to spend a huge amount of time fixing bugs later on, it is a lot of money! And a lot less bugs means much happier customers, so money again. Those are high ROI (Return On Investment) practices at medium and long term. They are not easy a first, but those who master them won’t go back to the old way, as it is so efficient.

Detect and fix the bugs when they are fresh!

It is proven that a bug takes 24 times less time to be corrected when fixed while the coder is still working (or has recently worked) on the part of the code where the bug is located. The buggy code is still fresh in his memory, so is easier to fix. If you wait, the bug will need more time to be fixed. Good teams detect bugs through Continuous Integration and efficient automated testing, and fix them right away. Do it too. You want to have a high coverage of your code with automated tests. Also, any time a bug takes more than 2 hours to be fixed, it’s time for a team brainstorm. You collectively check how the bug happened and why it took so long to fix it. That will lead to systematic improvement in coding practices (to reduce the occurrence of such bug) and bug analysis (to find out faster where it is and how to quickly fix it). Remember to share this knowledge with other teams, and keep it in the “problems and solutions” company log.

Keep the code elegant!

Once you’ve written the minimum code that has passed all your tests, refactor (meaning better organize, improve, clarify) it to make it really elegant. It should be well organized and commented/documented so that another member of the team can easily understand it and operate on it, whether to modify or complete it. Then check it for integration and regression tests to have it ready to deploy!

It’s DONE, it’s delivered!

As soon as a piece of code has passed all the tests and is DONE, integrate it directly into the trunk, not into a branch. This is called Continuous Integration. Branch integration might be used to test a fix for a particularly dangerous bug that originally passed all the tests, or to store a particular release version (useful when the switch to the newest release is not automatic for all users). Out of those few cases (and certainly few others), when a code passes integration and regression tests, it then should live in the trunk. So define a clear and quality based gated check-in policy, with an easy and quick rollback when integration fails, rather than integrating on branches. This way, when a code change is integrated, it means it is deployable, either when the PO decides there are enough new features to deploy a new release (Continuous Delivery), or automatically, as soon as there is something new in the trunk (Continuous Deployment).

Diffuse the skills!

Teams in Scrum are cross-functional, meaning the team is able to do a variety of task covering –ideally- all its needs, as any need for a skill not included in the team is an external dependency, and you want to have the least possible dependencies. Also you don’t want your team to be stuck if one of its members is, for whatever reason, not available (sick, holydays…). So you need to diffuse specialists’ skills in the team, so that the basic tasks of a defined specialty can be done by other members. Whether about code architecture, writing efficient tests or whatever other skill, the specialists are expected to teach other members of the team to do regular basic tasks of their specialty.

For code, pair programming (two coders working together on one task) is a really efficient way to diffuse skills. When coding the critical components of a task/story, or the lower layers of code your product will be built on, maximize the quality of the code with pair programming. Do this also when you face a task you are not familiar with, and for which you will need to spend time analyzing how to design and implement it. Two brains are likely to get a better and faster result, plus both of you will learn in the process. You also use pair programming when a dev team member is not familiar with a code environment, with a code technique, or when he is a junior. Pair programming helps a lot to level up the team’s coding skills.

When it is not about code, one can learn by observing the specialist doing a task, and having him explain at each step what he is doing, how and why. Team members excelling in their specialty, while also understanding and being able to do basic tasks of other specialties, are said to be T-shaped. You want a maximum of your team members to be T-shaped. Of course the transmission will not make every member a specialist in every specialty, but it will greatly help in limiting the risks of a missing skill (which would lead to a waste of time certainly), and it will also help all members to understand each other’s specialties better, facilitating understanding, estimation and interactions.

Diffusing skills is not limited to development teams: it is also efficient to have teams organized as Scrum teams at all levels of a company. In such a team you may have a market analyst and a lawyer (and others) working together, and you want each to learn the basics of the others’ specialties.

As diffusing skills takes time, but is a highly beneficial long term investment, you may include it in your backlog in the same way that you may introduce your kaizen (improvement decided at previous Retrospective meeting, as we will see later on) in the Sprint Backlog. It gives weight and a clear objective, helping to insure efficient transmission.

To work correctly, you shall use the tools and practices detailed above. They take time initially, therefore teams with heavy management pressure will often avoid using them. It is shortsighted, over time you will accumulate technical debt and your initially strong velocity (sure, you are rushing and giving up on long term quality) will slowly decrease because of a probably rising technical debt, and lots of bugs in future integration tests. Before switching to Scrum, Microsoft had one log of more than 35,000 bugs, and most of its related development teams’ time was dedicated to fixing them. With Scrum and good practices, they have reduced this log by more than 90% and greatly increased their efficiency. So the teams, the PO and the management must understand the interest of not rushing, but rather be consistent in quality. It is ok to rush and take in some technical debt to meet a market milestone, but it is not ok if that happens Sprints after Sprints, or if you don’t take the time in the next Sprint to clean the debt you left in the previous one.

How to integrate UX/UI and code/database architecture specialties in a Scrum project?

About UX/UI designers, you can have one, or more, as a team member full time, or part time (but try to avoid part-time), or if he is not needed that often, then he will be an external asset. External assets are dependencies, which means skills or tools or anything else required before completing part of your work. A poorly managed dependency will cause delays, so avoid that by limiting the number of dependencies, or organize efficiently to have no delay (like making sure the designer will have time to prepare the visuals your team needs to work on/with next week). It is however recommended to involve the designer when you refine stories that will need some design work.

As of being collocated with the designer, or having him stay with other designers, the advantage of the first solution is to have him fully understanding the team’s work, making his work more pertinent and allowing him to give inputs to developers to enhance the work in progress. The advantage of having him with his peers is that it favors collective creativity, and that leads to better design proposals. So I would recommend generally to have the designer collocated with the development team, but when there is an important design solution to define, have the company designers ready to meet together to generate collective creativity, this is a pertinent option. It surely takes time on every designer’s schedule, but at the company level it allows for strong creativity when it is really needed. Some more about UX designer inside or outside the team.

What about system design, database architecture?

You have to find the balance between emergent design, meaning developing the system along your actual needs, and the intentional design, meaning the big upfront view of your future needs. If you look at the whole product backlog, you see features that you are not actually sure to include, so adapting your system to them could be a waste of time (and so money) if at the end they are not part of the product, or if they have evolved so much by the time of their implementation that you need a lot of refactoring.

Extensive intentional design is what traditional waterfall (the old boring non agile methodologies) teams do, and that’s long, often too complicated for the teams to manage it efficiently, plus it includes in its scope many low or non valuable features, ending therefore with high technical debt built in. A good agile practice here is to look at the overall picture to see how the database/software architecture would look like if we were to include our most valuable features/functionalities, and develop only the part necessary to meet the needs of our present and future stories in work. Then, with time, as the product emerges, you will develop and improve its architecture, with probably the occasional need to refactor part of it. Agile architecture is mostly iterative, evolving on the needs of the current code being developed. It is an emerging architecture, with a bit of planned architecture to reduce future refactoring.

In Scrum the team is cross-functional, however it is not always the case and some companies wrongly use dedicated test teams and/or software architects. As you can find out on the ArchitectsDontCode page, if the official architect has lost touch with the code for some time, his decisions might not be really helpful for the team. So better have a coding architect, with his feet on the ground and hands on the code. And you want him to share his knowledge with the team, so that other members both improve their skills and understand the product’s architecture.

When scaling Scrum, a good practice is to have one member in each team designated to represent the team at a regular coordination meeting about the product’s architecture. Among them they will “elect” a lead architect, who, if you are using the Nexus framework for scaling Scrum, will then be a member of the Nexus team. Remember here (or learn if you have not checked the Nexus framework, that Nexus team members can also be part of an affiliated Scrum team, so the lead architect will keep working in his team, however when his contribution is required in the Nexus team, this has priority over his duty for his Scrum team. Do keep architects in Scrum teams, since you want to avoid the anti-pattern of ArchitectsDontCode. And also remember that being designated as the lead architect does not give magical authority, it is a coordinating function to help the product’s architecture stay coherent, it shall not mean that the lead architect’s voice will prime over others while taking decisions in the teams’ architects’ coordination meeting.

Architectural decision impacting other teams’ Sprint  Backlog items, or some Product Backlog items, must be discussed with the lead architect, and when critical with all other teams’ architects at a coordination meeting.

Architectural decisions that have impact only on the team will be made by the team. Again, it is not because a member is designated to represent the team as its architect that he has final call on the team’s architecture decisions: it is the team as a whole who decides. Logically, if one member has better skills, knowledge and experience about software architecture, then the team is likely to agree with him, which is very different from having him imposing his view. Even when a decision has no impact on other teams, the team may require external opinion, firstly from the lead architect. If the matter is complex, the team may ask the opinion of other teams’ architects, or even some expert’s opinion outside the Nexus if necessary.

When defining the product architecture, prefer a modular approach to limit the dependencies between the different modules/features/functions. Your aim is when you modify one module, it has ideally no impact on other modules. This will dramatically decrease the complexity of maintaining/upgrading the system. Each team will be able to work on their different modules independently from other teams. Again: dependencies are waste-prone, so you want to limit them.

Here is an interesting article about how to manage software architecture in an agile project.

Don’t be overwhelmed by changes, chose your own rhythm and keep improving!

Some of you reading all this could end up thinking “oh man, I don’t do a third of that, I’ m baaaad…”. Well, you’re not, just consider you have a chance to be way more efficient than you used to be. Some things are easier than others. TDD (and so BDD) is not easy, writing the tests before the code to pass them is a big change. Best is to start pair programming with someone mastering it. You have never pair programmed? Well, time to start, you’ll see it is efficient. And about tests, try to have at least 50% of your code covered by automated tests, it’s a good start.

Development Team Size

Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint. Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to manage. The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog.

On Scruminc.com, Jeff Sutherland explains they noticed that team’s interaction, and so efficiency, is best at 5 or less, each further member reducing a bit the global team interaction. In his opinion, at 9 members teams are often dysfunctional. So whenever possible do 5, else 4 or 6. When you reach 8, consider dividing in 4+4 when possible.

Some large groups of developers working on a single Product Backlog self organize themselves in various, changing teams at every Sprint, each team taking responsibility for few tasks. This solution can be effective if you are doing short Sprints and if all group members know each other well enough to be quickly efficient every time they arrange as a new team. This is clearly not a frequent practice.

The Scrum Master

The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.

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.

Scrum Master Service to the Product Owner

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

  • 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; and,
  • 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; and,
  • Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.

Scrum Master Service to the Organization

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.

A Scrum Master who does not manage, with the team, to identify impediments slowing its work, is failing. There is always something to improve. It is his role to help the team find out what is slowing it down, or on the opposite, and not always identical, what can make it be faster, or better, or both ideally.

One Scrum Master for multiple teams?

Possible. Jeff Sutherland prefers to have Scrum Masters working in the development team, so that the Scrum Master has a better understanding of how everything is going. But if the Scrum Master is not a techie (nor a designer, nor a tester…), and the team is performing well and is well aware of Scrum, then there is no problem being active on multiple teams, as long as his availability, or rather his lack of it, does not become an impediment itself!

Scrum Master also part of the dev team?

As stated in the previous question, yes, it is possible. Just make sure that you don’t mix the roles: being the Scrum Master does not make him/her more important in the dev team, when acting as a dev team member he/she is only that, a dev team member, not a team leader nor a final decider.

Scrum Events

Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum. All events are time-boxed events, such that every event has a maximum duration. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened. The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process.

Other than the Sprint itself, which is a container for all other events, each event in Scrum is a formal opportunity to inspect and adapt something. These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.

The Sprint

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints best have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.

Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.

During the Sprint:

  • No changes are made that would endanger the Sprint Goal;
  • Quality goals do not decrease; and,
  • Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a definition of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product.

Sprints are limited to one calendar month. When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month. Sprints also limit risk to one calendar month of cost.

Maintain consistency

Can we change the length of the sprint depending on the length of our next coherent group of stories? Nop. Not that you can’t, but it is recommended not to. The main reason is to keep the benefit of having consistency in the rhythm. It’s better for the team, and it’s better for the stakeholders. However, teams new to Scrum often need time to adapt to it, so they can start with, let’s say, three-week Sprints, and after many Sprints, decide that they’ll do even better with shorter feedback loops, and so switch to shorter Sprints. It is quite common nowadays to have efficient teams doing one or two-week Sprints.

If your stories are too big to fit in a short Sprint, maybe they are not refined (or sliced) enough, or the team is not “swarming” them. Slice them and enforce your stories readiness rather than trying to enlarge your Sprint to fit a too big story. Swarming a story means you have all the team focused on a particular story and its constitutive tasks, rather than each member starting a different story. Swarming reinforces communication, helps to diffuse skills, allows for better design through frequent team interaction and pair programming. So swarm your priority story, have it DONE, then start the next one. As the agile saying goes: stop starting, start finishing!

Scrum creators decided not to include tools in the framework, but their teams have used Extreme Programming tools since Scrum’s origin. If you want to be efficient, use them too. Use automated testing as often as possible to limit the number of manual tests, which are error prone and time consuming, and boring. Use Continuous Integration and Continuous Delivery, or if agreed with your PO, Continuous Deployment. BDD + automated testing + Continuous Integration are recommended to achieve hyper efficiency.

Don’t let your team be disturbed!

At any time, any interruption must go through either the PO or the Scrum Master, not directly to the team. If the Scrum Master is also a dev team member, pity for him🙂. If not, the team defines who will be the one dealing with interruptions. It can change on a regular basis or be stable, as the team prefers, but don’t let people come to the team’s room and question the whole team, that is the best way for everyone to lose focus, and that is exactly what you want to avoid.

Outside the room, on your Scrum team page visible to every passer-by (more about it later), you can put a small sticker on the name of the dev team member who is the actual contact point for interruptions. Else, put a small flag on his desk, so people coming in know who to talk to, rather than asking and disturbing the whole team.

Cancelling a Sprint

A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.

A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. But, due to the short duration of Sprints, cancellation rarely makes sense.

When a Sprint is cancelled, any completed and “Done” Product Backlog items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.

Sprint cancellations consume resources, since everyone has to regroup in another Sprint Planning to start another Sprint. Sprint cancellations are often traumatic to the Scrum Team, and are very uncommon.

Sprint Planning

The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team.

Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches the Scrum Team to keep it within the time-box.

Sprint Planning answers the following:

  • What can be delivered in the Increment resulting from the upcoming Sprint?
  • How will the work needed to deliver the Increment be achieved?


Topic One: What can be done this Sprint?

The Development Team works to forecast the functionality that will be developed during the Sprint. The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal. The entire Scrum Team collaborates on understanding the work of the Sprint.

The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team. The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.

After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.

The team’s speed is called velocity. Velocity can be measured in hours or in story points (more about it in the Product Backlog section). If your team is new, it is normal that you do not yet know your velocity, which you usually get by looking at the average number of story points you have done per Sprint over the last three Sprints. That is called Yesterday’s Weather Forecast. So for your first Sprint as a new team, just guess what you can surely do, and what you will maybe have time to do.

Effective work time on Sprint Backlog items is usually around 60% of the total work time

Remember that your effective work time will likely never be more than 80% of your total work time (coffee breaks, answering mails, helping a team member on a tricky point…). Also keep in mind that the team will have to spend 5 to 10% of its time refining the Product Backlog with the PO. Plus, when your product will be released, even in alpha or beta version, you will have feedback about bugs. Non urgent bugs should be added to the Product Backlog if they weigh at least one story point (you don’t add a bug story to change a single defective image on a webpage, you just do it…), and prioritized along other stories by the PO. Critical bugs should usually be treated asap, so always keep some margin to have time to treat those. For older products, consider also that your team will have to spend some time refactoring the technical debt, so the PO and the team have to define how much time they will invest on it. When planned, bugs or technical debt refactoring can be added as non functional items in the Product Backlog.

All in all, it is pertinent to set a reasonable Sprint backlog, considering that usually no more than 60% of the total working time will be spent on Sprint items, and a list of “could be” stories that will be picked up if the team empties its Sprint Backlog before the end of the Sprint. And of course, plan accordingly to the team members’ availability: training sessions, holidays…

Any extra work coming during a Sprint must go through the Product Owner, as he is the one giving priority to the tasks. That includes bugs: he will determine if a bug can wait and so be added to the Product Backlog, or if it has to be included in the current Sprint.

Always remember that teams that finish early accelerate faster, especially if you are a manager coming from a traditional organization where the norm is to, when a team meets its given objectives, put the target higher for next time to keep pressure on it. That does not bring good results. You will get more done initially, but over long term the team speed and quality will crash along with their motivation and happiness. Hyper efficient agile teams are motivated happy teams. Make it so.

Topic Two: how will the chosen work get done?

Having set the Sprint Goal and selected the Product Backlog items for the Sprint, the Development Team decides how it will build this functionality into a “Done” product Increment during the Sprint. The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.

The Development Team usually starts by designing the system and the work needed to convert the Product Backlog into a working product Increment. Work may be of varying size, or estimated effort. However, enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less. The Development Team self-organizes to undertake the work in the Sprint Backlog, both during Sprint Planning and as needed throughout the Sprint.

The Product Owner can help to clarify the selected Product Backlog items and make trade-offs. If the Development Team determines it has too much or too little work, it may renegotiate the selected Product Backlog items with the Product Owner. The Development Team may also invite other people to attend in order to provide technical or domain advice.

By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.

Sprint Goal

The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting. The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.

As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements the functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.

When your Sprints are one or two weeks long, it might be difficult to define a Sprint goal. Some scrumers accept the principle of having a goal spanning over a few sprints, guiding the team and keeping focus on a common target. If you do so, pay attention that the current goal does not feel too distant from the team’s day to day work, else the goal loses its purpose.

Daily Scrum

The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one. The Daily Scrum is held at the same time and place each day to reduce complexity. During the meeting, the Development Team members explain:

  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal. Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint. The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.

The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum. The Scrum Master teaches the Development Team to keep the Daily Scrum within the 15-minute time-box.

The Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum.

Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team’s level of knowledge. This is a key inspect and adapt meeting.

Focus on one story at a time, swarm it!

Jeff Sutherland advises to have the team swarming the Sprint Backlog story by story. Swarming helps getting things DONE, it reinforces communication, helps to diffuse skills, allows for better design through frequent team interaction and pair programming. In this situation the daily meeting will focus on how the priority story is progressing, rather than what team members are doing, which changes the questions from member centric to priority centric:

What did the team achieve yesterday on the actual priority story?

Is there anything blocking or slowing us on that story?

What will we do today on that story?

Based on the reference story (or stories), how many story points did you work yesterday on the priority story?

The last question is to keep the team focused on the actual priority (guys, this is our priority, don’t start something else if you can contribute). 

For those who studied kanban, you will find those new questions quite similar to the kanban daily meeting questions. Here, good Scrum practice has evolved toward dealing whenever possible with a single story at a time, swarming its tasks, so quite logically the focus moves to the story as the center of the team’s work.

Often, when a story is nearing completion, not all the team works on it, so you will have the next story started. You therefore ask the same questions for the priority 2 story if someone has started it. Still, some members could be working on something else than those stories in progress, for example to fix a critical bug on the live product release. For them it is useful to ask the original individual questions, so that the team knows what they are doing. For a critical bug, the PO may add it, in agreement with the team, to the current Sprint, and give it the appropriate priority.

If a team member picks up a new story, while there is still work to do on those in progress, or when there is a higher priority story above the selected one, then it is pertinent to find out why. A possible reason will be that the coder feels more comfortable with what has to be done in the story he started to work on, but that’s often not a good thing for the team: better team up and raise your mastery by doing pair programming on an actual priority story. A need for dedicated training can be identified this way, and some corresponding formation can be proposed. Remember: don’t start too many things, better swarm the actual priority and finish it early.

Sprint Review

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.

This is a four-hour time-boxed meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches all to keep it within the time-box.

The Sprint Review includes the following elements:

  • Attendees include the Scrum Team and key stakeholders invited by the Product Owner;
  • The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”;
  • The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
  • The Development Team demonstrates the work that it has “Done” and answers questions about the Increment;
  • The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates based on progress to date (if needed);
  • The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;
  • Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,
  • Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated release of the product.

The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.

Sprint Retrospective

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is a three-hour time-boxed meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches all to keep it within the time-box. The Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum process.

The purpose of the Sprint Retrospective is to:

  • Inspect how the last Sprint went with regards to people, relationships, process, and tools;
  • Identify and order the major items that went well and potential improvements; and,
  • Create a plan for implementing improvements to the way the Scrum Team does its work.

The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint. During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by adapting the definition of “Done” as appropriate.

By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.

Check what the team spent time on

The most important meeting over the long run when considering the team’s velocity, as it is here that you will find most of your improvements. Before the Retrospective, have the Scrum Master collect the team’s Sprint’s effective work, noted in the table next to the burndown chart, to produce useful Sprint metrics. It should contain the number of effective story points achieved by each member, divided into all the activities they have worked on: stories, fixing bugs, working on technical debt, or anything else. The team will have first hand information to visualize what they spent time on, what slowed them. It is an efficient useful tool for the Retrospective meeting, especially if your team used to say this retro meeting is boring and useless. Now they have stuff to think about and get something from it.

Here is an example of a chart and the record of daily activities, at the end of a week-long sprint.

On this burndown chart you can notice that there has been a notable rise in the Sprint’s scope due to a story being much bigger than estimated (size 21 on Fibonacci sequence, compared to a READY estimate of 8). The team negotiated with the PO and they decided to take that story (priority 2) out of the current Sprint. Another possibility would have been to take out of the Sprint the three lower priority stories, 4, 5 and 6. It is the responsibility of the PO to decide what to do when there is a scope creep in a Sprint. Probably the story 2 will have to be further refined, and surely sliced into smaller stories.

In spite of taking out an originally estimated 8 points story, after having invested 4 points of work on it, the team is still late on its planning and did not complete the last story (6). They over committed for that Sprint. Either they were too optimistic about their velocity, or they did not anticipate correctly the quantity of side work. We can see they spent 8 points on paying technical debt interests, but none to fix it. That is about 15% of the total work done this sprint, so the team should consider investing time to fix the debt, rather than spending time paying its interests. On the good side there has been only one small urgent bug to fix this sprint. Well, of course it would be better to have none, but having only one small bug is rather good, so it seems the team is efficient at implementing proper automated tests.

You also see that Julien spent about 30% of his time on “other” things, it will be useful to understand what exactly, as that is quite a lot. No blame or accusation here in the process, the purpose is to detect what is slowing each member.

About Alex, he worked alone on the story 5 for the whole sprint. Story 5 was estimated at an 8 points size, however Alex spent 15 points on it. Points are relative, so estimations of personal work vary a bit from one member to another. Still, 15 would indicate that Alex did some overtime work to complete the story, and yet it took him double the estimated time (well, complexity, not time, but that is quite related).

If the story required a specialized skill that only Alex has, then it is ok that he focused on it. However, it is not optimal that he is the only one to have that skill, and it would have been pertinent to have another team member learning the basics of that skill, through observation or, better, pair programming.

If the story did not require a special skill, then Alex worked separately from the team. He did not swarm the higher priority stories, he did not interact with the team, and considering how long it took him to complete the story, he did not ask/get any help or assistance when he faced some difficulties. There is obviously a team dysfunction to fix here. The Scrum Master should have paid attention to the fact that Alex started working on a lower priority while the rest of the team swarmed higher priority stories. Maybe Alex did not feel confident enough to work on the tasks of the stories 1 and 2, if so it is essential to understand why. Further training and/or pair programming with a more experienced developer would do much good.

Last, the total work line on the chart will show you when a team is distracted: the daily total work will slow down. It will also show you the total work done at the end of the sprint, versus the Sprint Backlog work.

Improve estimation skill

Also, tracking the team’s work will be useful to find out what the team failed to see when they originally estimated the stories, as we can compare the estimates with the real work they did to get it DONE. It will help them to improve. A pertinent visualization here is to display the stories by size of their original estimates. You should see that the smaller the estimate originally was, the closer to reality. It is more than often good to slice stories down (but not always, don’t slice for the sake of slicing, you must keep a story coherent).

In the above example, estimates VS reality are 8->9, 13->21 (and not completed, so could rise further later), 8->7, 3->5, 8->15 (no swarming, member working on his own, losing efficiency).

Fix the impediments’ root causes, not their symptoms

When you find an impediment, analyze it thoroughly. Don’t stop at the first explanation, don’t limit yourself to the first “why” question, or you will likely fix the symptom and not the cause. The root cause of a problem is often deeper than it seems. Use the 5 why technique, like in this example:

· The vehicle will not start. (the problem)

1. Why? – The battery is dead.

2. Why? – The alternator is not functioning.

3. Why? – The alternator belt has broken.

4. Why? – The alternator belt was well beyond its useful service life and not replaced.

5. Why? – The vehicle was not maintained according to the recommended service schedule. (fifth why, a root cause)

In that example, you could change the battery. Vehicle will start, sure, but not for long. If you look deeper, you will change the alternator belt. The problem is then fixed for this vehicle, but you still missed the root cause and you don’t improve your process. Only by improving your maintenance process will you prevent such problem from occurring again on other vehicles.

For major impediments, consider using the A3 problem solving technique, pioneered at Toyota.

And an interesting paper about an A3 problem solving implementation.

Make your team happy!

As Jeff Sutherland explains in his book “Scrum, the art of doing twice the work in half the time”, people work better and faster when they are happy. You do want this rise in team efficiency, because it can be really big and so highly valuable. Financial results show how the company did in the past, collaborators’ happiness shows how well it will do in future. Use the Retrospective meeting to ask each member, on a scale from 1 to 5, how happy he is in his job. And, on the same scale, how well the company is doing in his opinion. Ask what could be changed to make him feel even better at work, and what could be changed in his opinion to make the company better. This can give useful feedback on how to improve the work environment. Of course, don’t fall into complacency, the purpose is not to please for the sake of pleasing, don’t agree on 10 weeks of paid holidays just to make people happy… The trade should be a win-win situation for the employees and the company: feeling better to work better.

The average happiness metric can be kept and tracked over each Sprint.

Enforce your Kaizen!

Jeff Sutherland recommends including the defined improvement in the next Sprint’s backlog as a priority story, with its own acceptance criteria to get it DONE. This way, the team commits to apply the change. You can name it the Kaizen story.

Share your improvements!

If there is an improvement for your team, it might be helpful for others as well, so share it. Have a company-wide list stating impediments analyzed and the respective changes applied to fix them. At a point in your own team Retrospective meeting, give a look at other teams mix of impediments/changes, as it might be useful for your team too. Of course, not all changes are validated over time, some changes may not be as effective as intended, or have unexpected negative side effects, so pay attention to update the company impediments/changes list to keep track of which solution worked, and which did not and why.

Scrum Artifacts

Scrum’s artifacts represent work or value to provide transparency and opportunities for inspection and adaptation. Artifacts defined by Scrum are specifically designed to maximize transparency of key information so that everybody has the same understanding of the artifact.

Product Backlog

The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, its Product Backlog also exists.

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate and value.

As a product is used and gains value, and the marketplace provides feedback, the Product Backlog becomes a larger and more exhaustive list. Requirements never stop changing, so a Product Backlog is a living artefact. Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog.

Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product. A Product Backlog attribute that groups items may then be employed.

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be “Done” within the Sprint time-box. Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning. Product Backlog items usually acquire this degree of transparency through the above described refining activities.

The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.

Defining a product and its Vision

Before refining your backlog and estimating its items, it is necessary to create it. The Product Backlog evolves throughout the product’s life, and its creation often starts before the Scrum team is even selected. The company management will define a Product Vision explaining its essential characteristics (what we do) and expected outcomes (why we do), and let the team decide how to do it. The main users/customers of the product will also be defined. Remember the user is not always the customer: design software in a company is used by a designer but it is not the designer who pays for it. Also, for products targeting children, the parents are the likely buyers, so pay attention to distinct users and customers when necessary.

When the why and what –the qualitative aspect- have been agreed upon, it is important to make sure everybody has the same perception of the quantitative aspect. You may use the “cover story” game here: all participants explain what they would ideally like to read few months after the product’s initial release in an appropriate blog/magazine. That will help to ensure that everyone reaches a common understanding of how big the product’s impact shall be.

Once they have defined its Vision, they shall focus on fully understanding all aspects of the product, using the 7 product dimensions and Structured Conversation and other appropriate Business Analyst techniques like impact mapping to analyze them at a high level and give them a value. It allows a first selection of what we should do, depending on the value of each epic and story. Epics are high level actions of a product, to be divided into stories, themselves divided into technical tasks. Example: “As a private customer I want to buy a pickup so that I can carry wood and heavy equipment.” could be an epic, “As a private customer I want to compare the prices of local dealers so that I find the best prices” would be one of its constituent stories, and “calling the dealers” would be a task for that story.

On a regular basis, for example quarterly, it is a good practice to review the value given to the epics, as the market and legal environments evolve. Example: you plan to connect your product to a smart watch, but one competitor did it recently and the early customer reviews of this innovation are not enthusiastic, so you’d better understand why and accordingly adapt your backlog.

Organize your backlog with a story map

A proper way to organize an emerging product backlog is to do story mapping. Take all your epics and put them on a line on a wall with their constituent stories below them on a second line, using sticky notes. The line with your epics is the map backbone; it can be read from left to right in a chronological order, so that if you read the epics’ names adding “then” between each of them, it tells your product’s story from a user perspective: I “story 1” then I “story 2” then I “story 3”…

If we consider the creation of a website selling shoes, we would possibly have the following epics:

fill up the shoes research criteria,

consult the resulting list of shoes,

consult shoes details,

add shoes to my cart,


receive the shoes.

Reading the epic stories of a user on the home page: I fill up the shoes research criteria, then I consult the resulting list of shoes, then I consult shoes details, then I add shoes to my cart, then I pay, then I receive the shoes. The epic stories’ flow makes sense.

We will also likely have accompanying epics, like “manage my user account” and “contact customer support”. But we don’t need them now, it is too early, we first need an Earliest Testable Product to present our stakeholders and our test users/customers with the essential features of our product, and get feedback from them to improve it. Again, your core functionalities are what will make your product succeed, so try them out early to validate your assumptions about how users will react to them, before spending time and money on accompanying functionalities. However, while organizing your product core system, keep in mind the other non priority (but yet valuable) epics, to limit future refactoring.

Now that we have our story map backbone, we place the stories under their epics. Stories represent a more detailed flow than the epics, as they detail them into smaller steps. If we take the “pay” epic of the shoes website example, we can imagine the following stories inside it:

As you see you can still read them as a flow with “I… then”.

When a story is a possible variation of another one (meaning you could do this or that), place one above the other on the story map. Sometimes the variation links back to the original branch, sometimes it starts a new one.

The variations in the story flow can either be proposed to all users, or only to (a) specific type(s) of users. When a story flow concerns some specific types of users, then there are different story flows depending on what user we consider, as in the proposed impact map example where the product has three types of users who will each use a different aspect of it. Let’s call each different story flow an adventure. Some products offer the same adventure whoever the user is. Some products offer different adventures depending on what kind of user is using it. Some adventures will have multiple variations at various steps, some will have none, some variations will lead to separated branches, like a tree.

You must define who could use your product, and then how to best adapt your product to satisfy the different possible types of users/customers. Ideally this work has already started while defining the product Vision, but you nevertheless have to go further now.

Depending on your product, users could be vague like “private user”, or “corporate user”, or “man”, or “woman”. But sometimes it needs to be much more specific, so you would create fictional personas (or real if there is a perfect incarnation of your persona), with the appropriate profile and name. You don’t create personas for the sake of it: you create as many as there are different adventures you envisage to best fit the needs of the corresponding types of users. Each adventure is an ideal adaptation of your product experience targeting a specific type of users, represented by a persona.

If we look at the given impact map at the beginning of the previous section, you see three types of users: the fans, the concert organizers, and the agents. Do they each follow a different adventure in their use of the product? If so, as there are only three types of users identified, you can keep the basic titles of fan, agent and organizer, it shall be clear enough. But if you think you need to provide a different adventure to different kinds of fans, depending on their age, their gender, their musical tastes… then you define personas representing those different user types, and their adventures.

If you have many personas, it is preferable to represent clearly their distinct adventures on the story map. Keep one neutral color for the stories common to many user types/personas, then take different colors, or if you lack colors, shapes or whatever technique you think of, for the stories specific to each persona. You will quickly visualize which types of users need the most dedicated work. Therefore, depending on the value of each type of users, you will decide whether to create all or part of their specific stories, or nothing at all. Often a story specific to Perceval (nice name for a persona, isn’t it?) could be replaced by another one used by both Arthur and Lancelot, without losing much user value for Perceval. It is always a trade-off. How much value does Perceval represent for us? How much interest the product will lose for Perceval if we replace this specific feature by one non specific? How much does it cost to develop and then maintain this specific story? After answering those three questions, you will know what to do. Usually you will build high user value but low cost specific stories to keep a persona happy about the product, discarding those with low user value or high cost, sometimes you will just give up completely on some personas: sorry Perceval, we won’t adapt the product for you, not worth it, nothing personal, just business pragmatism.


The above map was created using realtimeboard.com. As you can see this one is organized by releases. Epics have been replaced by two levels: User Activities and User Tasks. Some scrumers will sometimes prefer talking of Epics and Features. Epics and stories, or Epics and Features and stories, or User Activities and User Tasks and stories… Your call, depending on your context and taste. What is sure is that under this one or two lines upper section, you will have stories.

Another difference between virtual and physical maps is that on a software the stories don’t need to be moved over to the Sprint board, they are automatically duplicated, and rather get stickers on them on the story map indicating whether they are being worked on (wip= work in progress) or DONE. Therefore there is no DONE line here. If you work by releases and don’t have already too many colors of stickers on your map (when using different colors for personas specific stories), you can use the same approach on your physical board, and so keep a clear track of past releases content. But if you do like me and use a DONE line, then take pics regularly of your map to keep track of its content and changes over time.

Here is a nice example of physical story map. Sorry it s a small pic, if anyone has a good, not messy, larger map, please send!

Now that you have all the personas, their shared or specific epics and constituent stories, it is time to prioritize them.

How to estimate the quantity of work

Once the Product Vision is defined and the initial Product Backlog is filled with valuable epics and main user stories, the Scrum Development team helps the Product Owner prioritizing the epics/stories. To do so the dev team will give a first high level technical estimate (that we may call early estimate) of the technical complexity of each story, using story points preferably, and will also define the main non functional items (we need a database to do that, we need to do a spike to try out this new technology, etc…) that will be required by the functional stories. User stories in Scrum are usually defined with the “As a <user type> , I Want <action> , so that <outcome>” structure.

Story points are linked to relative estimation techniques. The two more frequent relative estimation techniques are the t-shirt size and the Fibonacci sequence. Well, I think you get the principle behind the t-shirt size: is this story very simple to do? If so, it is a S size story. The second one is quite bigger, it’s a M size. Oh, and look at that one, even bigger, it’s a L size. You can go from XXS to XXL to determine the relative size/complexity of your stories. The Fibonacci sequence goes 0, 1, 2, 3, 5, 8, 13, 21… You add the previous number to the actual one to get the next one. Scaling iterations allows for wide margins so it is easier for team members to agree on a size. Note that a 2 points story is not necessarily 2 times bigger than 1 point story; don’t focus on the quantitative aspect of the comparison but rather on its purely relative aspect. A 1 point story is noticeably smaller than a 2, itself noticeably smaller than a 3, etc.

For both t-shirt size and Fibonacci, you need to select one or more stories of reference, relatively to which all others will be defined. You can define a 2 points and a 5 points stories of reference for example.

Experience has proven over and over that the relative estimates are more reliable than the hourly estimates. So drop the hours and switch to the story points. Over few sprints you will get your velocity and you will be able to give your management a time schedule, by releases of by sprints. Between the t-shirt sizes and Fibonacci, I prefer the Fibonacci, but it is really up to you.

And you can easily find Fibonacci sequence cards to play Planning Poker when the team estimates the backlog stories. When playing Planning Poker, team members don’t give their estimates, so that no one is influenced. Each member puts a card face down corresponding to his estimate of the current story analyzed. Once everyone has played a card, they re turned face up. If there is no more than one iteration between the lowest and the highest estimate (for example all cards are 3 and 5), then you calculate the average and it is your story size. Else both higher and lower estimate explain how they view the story, to reach a shared understanding of it. Then the team repeats this loop until all cards have no more than one iteration range.

Refining the backlog and selecting high value items

80% of the value is usually concentrated in 20% of the features you could consider adding to your product. So estimate the rough ratio value/cost of each story (keep it high level, don’t pay too much time being super precise at that time, remember than most of the stories with low value you are now estimating probably won’t be included in the product), removing the non valuable stories (but keep them somewhere for later, we never know, environment can change, new needs arise…). The value is not necessarily the ROI (Return On Investment), it can also be non financial benefits. The cost is usually mostly the development time (for software products), best estimated in story points. To be sure to not forget any important aspects of a story, use (again!) the 7 product dimensions.

Once you have given a value to each story, and taken away those with a low ratio value/complexity (value points/story points), you prioritize the remaining stories, the valuable ones. A good way is to divide your story map into sprint lines if you do continuous deployment. Otherwise, if the product owner defines sets of features to be included in future product releases, then your lines will be per release. Right under the epic names (or above if you prefer), you have a rather large DONE line, where you will put all the stories once they are DONE. Then you have the next sprint line -sprint +1- (or release 1 if it is per release…), then sprint +2, sprint +3… In each line the PO includes the stories he would like to get DONE, according to their estimates and the team’s velocity (NB: mind the dependencies!).

Remember that early estimates are often wrong, and even refined estimates are frequently wrong. Add a +50% margin to the early estimates to calculate your later sprints, and still add +30% to refined stories. At the end of each Sprint, in the Retrospective meeting, you will compare the average early and refined estimates to reality, so you will modify those percentages according to your team’s reality. You will also see what stories went really wrong at early and/or refined estimates. It will help you to improve your estimate skills: the objective is to have both early and refined estimates margins as small as possible, which will improve the reliability of your release plan.

If your story map lines are per release, add all the story points of the stories of each future release and divide the total by the team’s velocity to have an idea of your completion date. Knowing how many Sprints will take each release means you have a release planning to share with your management and stakeholders. So you get a release planning when you define versions to release to your customers/users. How then do you name the product planning when you do continuous deployment? There are no releases: every time some new functionality is DONE, it goes live. Some call it road-map, others features planning, Mike Cohn calls it long-term planning. As for me, I find it simpler to just call it the product planning. Your call, just make sure all stakeholders, team members and interlocutors know what you mean when using a term.

An agile release planning –or product planning :)- is not a certain data, it is an indication that is likely to evolve over time, depending on Product Backlog refinement, the team’s velocity, and what the market and feedback loops will generate as changes (if there is no change between starting and completing the product, either you are all incredibly good, or more likely you did not set up the appropriate feedback loops). Pay attention when submitting a release plan to your stakeholders, make it clear it is an indication, not a guaranteed planning.


As a team it is recommended to define a moment in the week when you spend one hour refining the Product Backlog. Stories that are not READY usually fit on a small sticky-note, with:

their name,

their description (often with the “As a <user type> I want <action> so that <outcome>” structure),

a reference number,

an early estimate of its complexity,

its business value.

It may include more info, like its main acceptance criteria on the back, who created it, or whatever is useful. When you make a story READY, you’ll have much more info about it, so I personally then use bigger sticky notes for READY stories, around A5 size.

When creating a new functional story, remember to always write it from a user perspective. Non functional stories can be trickier. When it is about adding an administration back office, then write the story from its user (administrator) perspective: as an administrator I want a back office so that I can control this and that and do these and those. When it is about adding a security control to the main database access, well, it is ok if you don’t use the “as a X I want Y so that Z” format, the purpose is to know “what” and “why”, as there is no clear “who” in this case.

Whenever you refine your stories, remember to always indicate the dependencies, whether between the stories themselves, or with elements outside the team: skills, some special tool or software you will need, some validation/confirmation… It is especially important if you have many teams working on a single product. Dependencies can easily generate lots of waste and technical debt if not taken care of. Good teams reduce dependencies a maximum, and much is done about it by correctly refining the Product Backlog. When refining, keep in mind the 7 product dimensions, it is a pertinent base to be sure not to miss an important aspect of a story, and to define pertinent acceptance criteria.

And remember: always get your next sprint’s stories READY! (although you may start the first sprint with some stories not yet READY, you will have to READY them before starting them)

Are your stories INVEST? Independent (no blocking dependency), Negotiable (clear enough for the team to have a common understanding of it and discuss it), Valuable (well, if you have selected stories based on value, those remaining are hopefully valuable), Estimable (usually if it is negotiable, it is clear enough to be correctly estimated), Sized to fit (when it is too big, slice it), Testable (clear acceptance criteria).

Stories not READY will generate waste (coders will lose time understanding it, or waiting for clarification or dependency, or will build something that is not exactly what the PO expected), it is proven that READY stories help the team work better and faster. So it is clearly not a loss of time to work on it, to INVEST🙂

Being READY includes having external dependencies dealt with, for example having UX and UI designs work done. Oh, of course, you don’t have to ask those guys to work on all the stories of your backlog, only those which will surely be included in a near sprint. If you used the 7 product dimensions, you have also checked the legal and technical compliance, and that your stories respect all company norms.

A good READY story card may present (1 to 5 on the front, rest on the back):

The story name

The story tracking reference (P39E1S12 would mean product 39 Epic 1 Story 12)

Story description (as a X I want Y so that Z)

Estimated size: high level early estimation, refined estimation when READY, total work invested once DONE.*

Estimated business value**

The internal dependencies for this story (list the other stories or tasks that must be DONE before the work on this story can be started)

The internal dependencies from this story (list the stories or tasks that can’t be DONE before this one is DONE)

The external dependencies for this story (skills, information, tools, equipment or other team work that must be available)

The external dependencies from this story (which team/customer/else is waiting for this story to be DONE to do something)

Time tracking: when was the story submitted, by who. When was the story validated by the PO. When was the story READY. When was it included in a Sprint Backlog. When was it DONE.

List the story acceptance criteria. Think also about how you will demo the story at Sprint Review, it may lead to additional criteria.

Once READY, list the tasks. Add the tasks eventually discovered during the Sprint. It is useful for a new member in the team to see what has been technically done for the different stories.

Other: add any useful info. Could be links or references to some documents (UX design work for the story), the .feature file of the story’s BDD acceptance tests, a reference to a compliance document, or whatever that may influence the way the dev team will work on it.

* Keep those estimates and use them at the Sprint Retrospective meeting. When, at early estimate, we find a very large story, I prefer to divide it right away into smaller ones. It takes a bit more time but it also makes for a more reliable release planning, and a more accurate view of dependencies, therefore helping to identify some risks earlier. If a refined story is divided into smaller ones, divide the previous bigger story’s early estimate between the newly created stories’ early estimates, and make sure to update the dependencies references on both the new cards and the stories which previously referenced to the big story being divided.

**not only financial value, example, a car maker investing money in a formula 1 team gets no direct financial benefit from it, but it gets technical excellence and a boost in the brand image. Biz value can be relative, the way you do story points, or you can define a Present Net Value and/or cash flow prediction and/or ROI for an epic, then dispatch its total value on the stories constituting this epic. The ratio of biz value/story points gives the value/complexity of an Epic or a story, a strong indicator for prioritization.

Continuous compliance

Your company or its clients may have norms/laws to respect. Those will impact your product, not just at its creation, but over time as those norms/laws may evolve. When you refine your stories, pay attention to reference those external compliance requirements. Ideally, you will write directly their real reference/name/codification, so that when a law/norm evolves, you will easily find which stories were impacted.

Checking regularly that your product complies with those extra requirements can be critical. So whenever possible, add automated compliance tests to your regression tests. And make sure that you get informed, in one way or another, when a change of a norm or a law impacts your product. Here is an interesting article about Continuous Compliance.

Involve your customers, validate your early assumptions

Whenever you create a product, involve your customers early on and often! Don’t build over a non pertinent foundation: put your product in customers hands early and see what they like and don’t like. As Eric Ries explains in his “lean startup” book, it is essential to have early real feedback on your emerging product. You first create a mock up or a prototype of your product with its core functionalities, and you present it to test users. Their reactions and opinions will help you to better understand how to meet their needs, it will help you to improve your product and the assumptions it is built on. This early and then regular feedback cycle allows you to correct or validate your assumptions, and so reduce your risks.

To validate your product assumptions as early as possible, organize your backlog to deliver quickly the set of functionalities required for a Minimum Viable Product (MVP). You will find this term in many agile topics, as it describes the state of a product when the PO estimates it has the minimum characteristics to go live on the market. However, like Henrik KnibergI don’t find the term very appropriate, and I prefer his option of speaking of an Earliest Testable Product (your test customers will try it because you ask them to do so, and you’ll have early feedback), then Earliest Usable Product (you’ve improved the product based on the early tests, and now users can use it quite easily, but it is not good enough yet so that they would buy it), then Earliest Lovable Product (they love it, they keep using it and if they were not your test customers they’d rush to buy one, and they would spread the word!).

Once the Early Testable Product is improved and validated, you’ll build a first releasable version with just its core features: the Earliest Usable Product. If you did the early prototype feedback loops correctly, your product now meets your target users/customers needs, so they should use it. If so, then you are good, you have a solid base to build on. Add other valuable features so that the users don’t just use your product, but also love it and recommend it to others. You read the adjective “valuable”, it is really essential, don’t add functionalities just because you have a dedicated development team that you must keep busy. Adding low value features to a product adds to maintenance costs and UX complexity, which diminishes its interest for most of its users. Don’t do it. If you re not sure of a functionality’s value, then mock it up and present it to test users, to have their opinion. If they like it, make it real and check how they use it, you may learn again something new. Early and continuous learning about your users’ needs is key to limit risks and raise your chances of success.

That means: focus on validating the core functionalities of your product by releasing early. That is the spirit of Scrum, releases and users feedback iterations are aimed at keeping improving both your product and the way you create it.

When discussing features and functionalities, keep in mind that what is really important is not the feature itself but the user’s need it meets.

Reduce the risks!

When prioritizing your Product Backlog, you also need to balance priorities between internal and external risks. Internal risks are linked to the product development itself: do we know how to create it, do we have all the skills necessary, are we sure the technology we plan to use will give the expected results? Those are risks you want to get rid of early on in the project, to be sure that you are not investing time and money for nothing. External risks for commercial products are mostly related to our customers’ reactions: will they like it, will they use it, and, even more, will they buy it? Have we correctly defined who our customers are?

If you are building a product at the demand of a client, then your external risks are limited, since the client has already explained to you what he wants (and why) . Usually you will focus more on the internal risks in this situation, but you still want to have early feedback on the emerging product, to be sure that what you are creating meets the client’s real needs (which can be different from the originally presented needs).

Balance the priority of your backlog between your internal and external risks, organize the backlog to both quickly release an Earliest Testable Product (especially for commercial products) and confront the highest internal risks. Don’t include non-core functionalities in your product before confronting reality with it. Better fail fast and adapt, than fail after completing the whole product and having expended all your resources, as then it is too late to adapt.

Monitoring Progress Toward a Goal

At any point in time, the total work remaining to reach a goal can be summed. The Product Owner tracks this total work remaining at least every Sprint Review. The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal. This information is made transparent to all stakeholders.

Various projective practices upon trending have been used to forecast progress, like burn-downs, burn-ups, or cumulative flows. These have proven useful. However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has happened may be used for forward-looking decision-making.

Sprint Backlog

The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.

The Sprint Backlog makes visible all of the work that the Development Team identifies as necessary to meet the Sprint Goal.

The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.

As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.

Sprint board

Next to the story map will be another board where you will move all the stories taken from your Product Backlog (in our way of doing things, the story map itself) to fill the Sprint Backlog. This new board has one line per story selected, and has usually four columns: Stories, To do, Doing, DONE. In the story column you have the story cards. In the To do column you have the list of all the stories constituent tasks. In the Doing column are placed all tasks actually worked on by a dev team member. In the DONE column are all the tasks that are DONE.

Tasks are usually written on small sticky notes, with:

their name and description on the front, and a reference number,

eventual task dependencies on the back,

who worked on the task, since when,

who reviewed it,

when it was DONE.

When a dev team member picks up a task, he writes his name and the date on its back. Once completed and tested, he writes the date, then has it peer-reviewed (reviewing all substantial coding tasks should be part of your DONE definition for the stories). It is not necessary to peer-review a code that has been pair programmed. The reviewer, after validation, writes the date and his name on the back of the task card.

Some calls this board the Scrum Task Board, others calls it just Scrumboard. I prefer to call it Sprint Board. Whatever you call it, it is essential to have one. Many software versions exist, however it seems physical boards still are favored by most of the teams. Note that you can use both a physical board and a digital one, as each has advantages. Combined with a story map used as a Product Backlog, it is really efficient. At Sprint Planning meeting you move cards from the story map to the Sprint Board, and at the end of the Sprint, cards will move back to the story map, in the DONE line for those who were DONE, in the next Sprint line (or lower, as the PO decides) for those not DONE.


The above example by the way shows that the team is not swarming the actual priority story: story 2 has one remaining “to do” task while story 3 has some tasks already completed. Remember that to reach hyper efficiency, it is recommended to have the team swarming the actual priority story.

At the end of a sprint, the DONE Sprint stories are put back on the story map, in the DONE line if you use one, or in their release line with a DONE sticker (or anything else visual enough). The stories that are not DONE are brought back to the Sprint+1 line, and the PO takes note of the updated team velocity, so he will adapt his assumptions of what can be done by the next Sprints. Soon after the review meeting, at the next Sprint Planning meeting, the PO checks with the team to define what stories will be taken to the Sprint. So the story map is regularly updated, considering the team evolving velocity, and the external feedback loop (from the market, from the test users, from the stakeholders…).

Monitoring Sprint Progress

At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress.

Keep note of what you spend time on

Usually teams will use a Sprint burndown chart. You’ll find plenty of examples about how to create one. One good thing is to add a line under the graph, indicating when the Sprint scope is changed, of how many points and why: could be a story added or taken out after negotiating with the PO, could be an unexpected task added to complete a story, could be the team realizes it massively failed to estimate the complexity of a story…

Also, daily track the amount of story points worked on. As we saw, the team regularly has something else to work on during a Sprint than just the Sprint Backlog items. During the Sprint, whenever you spend enough time on something, let’s say more than two hours in a week, you note it, whatever it is.

Next to the graph, indicate the time spent on each story, on technical debt, on fixing bugs, and on other stuff. That will be a good indication to understand what is going on, and it will be useful for the Retrospective meeting, to find out what is slowing the team. And when you see that the Sprint is really going wrong, check with the PO and the Scrum Master to understand why, and to adapt so that you can still save the Sprint goal. Else, it might be necessary to abort the Sprint and start a new fresh one, on a clean basis.

You can use a chart and a work table like in the below example to track the daily team work, and add them every day to the second table covering the whole Sprint.


The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be usable and meet the Scrum Team’s Definition of Done. It must be in usable condition regardless of whether the Product Owner decides to actually release it.

So many teams fail to understand that this means you should have AT LEAST one increment per Sprint, and not that you can have only one increment per Sprint. When googling the topic, you will find plenty of posts and articles where people complain that they must wait for the end of a Sprint to release a new version, and so they switched to kanban to do Continuous Delivery or Continuous Deployment. Those people fail to understand Scrum. Scrum events, artifacts and values are made to get the best of the teams. In absolutely no way it means to limit their efficiency, it is completely opposite to its “raison d’être”. Jeff Sutherland has said it many times, some of the best Scrum teams release new versions every single day, sometimes many times a day. If your PO and the stakeholders agree with a Continuous Deployment strategy, then so be it. You will get early feedback from the users, it fastens the feedback process, that’s good! Still you meet all stakeholders at the regular Sprint Review meeting, that does not change. The difference is that if you put some feature on the market early in a Sprint, then by the Sprint Review meeting you will already have early user feedback to adapt next Sprint’s work, it’s great!

Artifact Transparency

Scrum relies on transparency. Decisions to optimize value and control risk are made based on the perceived state of the artifacts. To the extent that transparency is complete, these decisions have a sound basis. To the extent that the artifacts are incompletely transparent, these decisions can be flawed, value may diminish and risk may increase.

The Scrum Master must work with the Product Owner, Development Team, and other involved parties to understand if the artifacts are completely transparent. There are practices for coping with incomplete transparency; the Scrum Master must help everyone apply the most appropriate practices in the absence of complete transparency. A Scrum Master can detect incomplete transparency by inspecting the artifacts, sensing patterns, listening closely to what is being said, and detecting differences between expected and real results.

The Scrum Master’s job is to work with the Scrum Team and the organization to increase the transparency of the artifacts. This work usually involves learning, convincing, and change. Transparency doesn’t occur overnight, but is a path.

Definition of “Done”

When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this varies significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment.

The same definition guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning. The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current definition of “Done.” Development Teams deliver an Increment of product functionality every Sprint. This Increment is usable, so a Product Owner may choose to immediately release it. If the definition of “done” for an increment is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum. If “done” for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of “done” appropriate for the product. If there are multiple Scrum Teams working on the system or product release, the development teams on all of the Scrum Teams must mutually define the definition of “Done.”

Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.

As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality. Any one product or system should have a definition of “Done” that is a standard for any work done on it.

DoD: in Scrum it does not mean Department of Defense, it is the Definition of Done, but be sure that if you don’t define it up properly and your competitors do, they will blow you out of the market. Department of Defense has its MOAB (Massive Ordnance Air Blast, aka the mother of all bombs); agile software development has the Definition of Done as its anti-MOSB (Massive Ordnance Software Bloater). Neglect your DoD, and you will accumulate technical debt and slow over time, endangering your company’s agility.

Here is a recommended, to be completed relatively to your situation and context, list for your DoD.

  • BDD examples tests (named Unit tests in TDD) and scenarios tests (Acceptance criteria tests, or features tests, in TDD, BDD using Given-When-Then language that ease communication and tests elaboration between the dev and the PO/BA), security tests, performance tests, accessibility tests, UI tests…: all passed.
  • Code refactored to be elegant after all tests are ok (no technical debt included),
  • Code commented/documented,
  • Code peer-reviewed (when not pair programmed),
  • For new features or visible changes client-side, user documentation has been updated,
  • Integration tests passed,
  • Regression tests passed
  • and if you do Continuous Deployment: story implementation has been validated by the PO


End Note

Scrum is free and offered in this Guide. Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.



Of the thousands of people who have contributed to Scrum, we should single out those who were instrumental in its first ten years. First there was Jeff Sutherland working with Jeff McKenna, and Ken Schwaber working with Mike Smith and Chris Martin. Many others contributed in the ensuing years and without their help Scrum would not be refined as it is today.


Ken Schwaber and Jeff Sutherland first co-presented Scrum at the OOPSLA conference in 1995. This presentation essentially documented the learning that Ken and Jeff gained over the previous few years applying Scrum.

The history of Scrum is already considered long. To honor the first places where it was tried and refined, we recognize Individual, Inc., Fidelity Investments, and IDX (now GE Medical).

The Scrum Guide documents Scrum as developed and sustained for 20-plus years by Jeff Sutherland and Ken Schwaber. Other sources provide you with patterns, processes, and insights that complement the Scrum framework. These optimize productivity, value, creativity, and pride.

Here you are, we are DONE🙂 and now you should be READY to scrum efficiently!

Remember these good practices are not exclusive; there are other ways you could use depending on your context. But if you understand Scrum, and the “why” behind the framework and all the good practices I have presented, then you should be able to adapt it to your particular situation. Never put the framework above an obvious better option if there is one at some point, that would be Zombie Scrum, and you don’t want to be a zombie. To truly understand the “why” behind Scrum, I strongly recommend you (no, I order you to) read Jeff Sutherland’s book “Scrum, the art of doing twice the work in half the time”. It opened my mind to the true understanding of Scrum and agile. And it will surely do so for you too.


Necessary legal statement : This is a derivative work by Arnaud Viguié based on The Scrum Guide. No endorsement is made by either Jeff Sutherland, Ken Schwaber, or any of their related commercial entities. The original Scrum Guide is offered for license under the Attribution Share-Alike license of Creative Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form athttp://creativecommons.org/licenses/by-sa/4.0/. By utilizing this you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of CreativeCommons.