c ert i fi ed scru mm ast er - agil8 · + 44 (0) 207 796 9903 [email protected] c ert i fi ed...

www.agil8.com+ 44 (0) 207 796 9903 [email protected]

Certified ScrumMaster(CSM)

Live Online Training Workbook

With David Hicks

@AgileDave

@Agil8er

Course Notebook Contents

© agil8 - ScrumMaster Training v5.1 1

• Introduction ……………………………………… page 1• Scrum and Agile Background ……………. page 4• Scrum Framework Overview ……………. page 11• The Product Backlog ………………………… page 22• The Scrum Team ……………………………… page 29• Sprint Mechanics …………………………….. page 39• Next Steps ………………………………………… page 53

How to Use this NotebookThis Notebook includes copies of the training course slides plus additional notes for your reference. There is a tear-out Feedback Form at the very back of the course book that we would like you to complete for the trainer at the end of the course.

Our Working Agreement for the TrainingAny team should agree its working rules and norms of behaviour. Here we suggest :1. Commitment : please be here and commit your time and attention to the class2. Focus : please focus on learning, resist distractions and side conversations3. Openness : to new perspectives and new ideas; and be open about your needs4. Respect : respect each others views and respect each others time5. Courage : have the courage to challenge orthodoxy and the status quo

Page 1

This course book includes areas for you to make your own notes or fill-in with your own thoughts to help you embed your learning. This may be done during the course or in your own time afterwards as follow-up. These areas are marked in yellow to be clearly visible. Please use them as you see fit.

© agil8

agil8 Scrum Master Training Course Notebook


Agil8 is a world expert on Agile and one of the UK’s leading specialist Agile Consulting and Training providers. We help organisations and individuals to better understand Agile and apply its principles, practices and methods to best effect in their work.

Agile Transformation Consulting, Coaching and In-House TrainingOur corporate clients include both private and public sector organisations, large and small, across all industry sectors. They range from start-ups and digital agencies to blue-chip technology, engineering, retail and financial services and consulting companies. Our services include Agile Consulting and Coaching in support of Agile Transformation initiatives and in-house training in all flavours of Agile and all its aspects from Executive Briefings to hands-on Agile Team training and technical Agile programming courses.

Agile Public TrainingWe also run a full range of Certified public training classes across the UK in all of the leading Agile Methods. These are attended by permanent employees and freelance contractors and consultants looking to improve their skills and understanding in Agile. Most often they are working in technology focused roles as Change, Project, Programme, Product, Account or Infrastructure and Operations Managers, Consultants, Coaches, Scrum Masters, Product Owners, Analysts, Designers, Programmers or Testers . We also have a growing number of course delegates from other disciplines such as business operations, sales and marketing.

Agil8 TrainersAgil8 Consultants and Trainers are leaders in their field of expertise. They are multiple award winners with many years of practical experience in applying agile approaches, and in effective teaching , training, coaching and consulting methods both inside the classroom and outside in real-world situations.

Page 2© agil8


David Hicks• Agile Consultant, Coach & Trainer• Agile Alliance Founder in 2002• Agile since 1994: British Airways• Scrum since 1998: Heathrow T5• Kanban and Scaled Agile since 2008• World’s only Certified Agile Trainer for:

– Scrum– Kanban– Scaled Agile– AgilePM

• 2015 Agile Award Winner: voted the“Most Popular Scrum Professional”


[email protected]@AgileDave

Page 3© agil8


David Hicks is a Founder of the Agile Alliance and, with over 30 years experience in Agile, he is one of the most qualified and experienced Agile consultants and trainers in the world. In 2015 David was voted ‘Most Popular Scrum Professional’ in an online poll for the annual international Agile Awards which recognise outstanding contributions in the field.

David’s journey in Agile began in 1987, through his MSc thesis on iterative development which was published by the British Computer Society. He started his professional career in 1988 as an analyst-programmer, team leader and ultimately project manager with LBMS, the originators of the PRINCE and SSADM methods. David was responsible for defining LBMS’s first iterative SDLC and worked with early 4GLs and client-server applications doing iterative development in the early 1990s.

David established himself as an independent consultant in the mid 1990’s and became a key figure in the DSDM Agile community in the UK. From 1997-2001 David was hired by British Airways to manage the World’s first Enterprise Agile Transformation as it transitioned its entire 5,000-strong IT organisation from Waterfall to DSDM. He managed the team of agile consultants, trainers and coaches on this programme for 4 years, during which time he provided consulting advice to the Heathrow Terminal 5 project, which is where he first started using Scrum in 1998.

Since then David has founded and been the CEO of two agile consulting companies and has managed Agile Transformation teams on some of the largest and most complex Agile implementations in the world. He has expert level and practical experience in the complete range of today’s methods and has personally Certified in excess of 10,000 people in agile as a Certified Scrum Trainer (CST), Accredited Kanban Trainer (AKT), Certified AgilePM/DSDM Trainer and SAFe Program Consultant.




What is Agile and Why Use an Agile Approach?The single most important question to consider when using Agile is “why”? Why do it? Scrum and Agile is not an end in itself, it is a means to an end. Agil8 has years and years of experience with Scrum and Agile, and what we have learnt over that time is that those teams and organisations who are most effective with Agile are those teams and organisations who are clearest on why they want to do it. What improvements do you hope and expect to achieve by using Agile and how are you going to measure those improvements? What does success look like for you? Those teams and organisations that have given this some thought tend to get the most out of using an Agile approach. Those teams and organisations who are doing Agile just because everyone else seems to be doing it, don’t get the most out of it.

This module examines the rationale and background to Agile and helps you understand how Scrum fits within the wider landscape of Agile approaches generally.

Page 4

For your notes

© agil8


The Agile Manifesto (2001)

We are uncovering better ways of developingproducts by doing it and helping others to do it.

Through this we have come to value:Individuals and interactions over processes and tools

Working product over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a planThat is, while there is value on the items on

the right, we value the items on the left more


The Agile Manifesto was created in 2001 at a ski-lodge retreat in Snowbird, Utah when some of the leading lights from the various emerging methods of the time got together in recognition of the fact that they all had something in common that set them apart from the then-dominant waterfall approaches of the day.

Discussions culminated in agreement on the statements above. Back then, at the turn of the century, it was becoming clear that the world was changing. Software was proliferating, the internet was becoming more and more important and the pace of change and progress in business and IT was increasing. The waterfall approach was beginning to look more and more strained, even a little irrelevant … focussing too much perhaps on the items on the right, and not enough on the items on the left.

Since then Agile approaches have become more and more popular, and are increasingly used beyond software development. A more up-to-date version of the manifesto might refer to “products and services” instead of software.


© agil8 Page 5

For your notes

Principles Behind Agile Manifesto1. Early and continuous delivery of valuable product2. Welcome changing requirements for customer’s advantage3. Deliver working product frequently4. Business people and developers must work together5. Build teams around motivation with support and trust6. Face-to-face conversation is most effective7. Working output is primary measure of progress8. Maintain a sustainable pace of development9. Continuous focus on technical excellence10. Simplicity to minimise wasteful work11. Self-organizing teams deliver the best results12. Reflect regularly, tune and adjust to become more effective© agil8 - ScrumMaster Training v5.1 6

The full text of the Principles behind the Agile Manifesto is as follows:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software (i.e. product)

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

3. Deliver working software (i.e. product) frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.5. Build projects around motivated individuals. Give them the environment and

support they need, and trust them to get the job done.6. The most efficient and effective method of conveying information to and within a

development team is face-to-face conversation.7. Working software (i.e. product) is the primary measure of progress.8. Agile processes promote sustainable development. The sponsors, developers, and

users should be able to maintain a constant pace indefinitely.9. Continuous attention to technical excellence and good design enhances agility.10. Simplicity - the art of maximizing the amount of work not done--is essential.11. The best architectures, requirements & designs come from self-organizing teams.12. At regular intervals, the team reflects on how to become more effective, then tunes

and adjusts its behaviour accordingly.

Page 6

For your notes

© agil8


Empirical and Defined Processes


Complexity andCreativity inOrganizationsRalph Stacey, 1996

Page 7© agil8

Process Control Science draws the distinction between Defined Processes and Empirical Processes. In a Defined process you define and plan-out all the steps in the process before you start the work. You then try to execute the plan, as planned, in order to achieve the desired end result. Process Control Science points out that this kind of approach is most appropriate when you are operating within a relatively simple, and therefore essentially predictable environment - where the requirements and solution for instance can both be defined in detail and fixed right at the beginning with no risk of disagreement or change. If we are trying to achieve something that is more complicated, or even complex, and therefore less predictable, then according to Process Control Science a Defined process becomes less and less appropriate, and what we should look at using instead is an Empirical process. With an Empirical process you don’t plan everything in details up-front. Rather you establish an overall objective and start moving towards it by taking one baby step at a time. On completion of each baby step you do three really important things. 1. You reappraise your overall objective to see if it has shifted at all, or if you have learnt anything new about it. 2. Secondly you get all relevant stakeholders to assess the deliverable from the baby step just performed and see if they are fit for purpose, moving in the right direction or need to be modified at all. 3. Thirdly, and just as importantly, you assess the way you are working, your organisation, procedures, practices and standards to see if you are working in the best possible way, and if not you change the way you are working. All Agile approaches are Empirical approaches. They are very different way of controlling the work. A way that is particularly appropriate when what you are doing is complex and unpredictable. Increasingly the work we are doing is of this nature, so it is no surprise that Agile approaches are replacing traditional approaches.


Empirical Process Control

Transparency Inspection Adaptation


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. Three pillars uphold every implementation of empirical process control:

Transparency 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.

Inspection 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.

Adaptation 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.

Page 8

For your notes

© agil8


Waterfall

• Delivery Lead time?• Communication?

• Responsibility?• Transparency?

• Change?• Quality?

• ROI?


Analysis

Design

Build

Test

Release

The Chinese Whispers ProblemSilo working and handoffs betweeneach stage lead to misinterpretationof specifications, poor collaborationor even blame when things go awry.

Difficult, Slow and Expensive to Accommodate ChangeA complete set of requirements is locked-down at the start, and a large complex designis established to deliver them. Both are difficult, slow and costly to change.

Inadequate Testing undermines Business Case & Return on InvestmentThe testing phase is often squeezed, leading to reduced benefit delivery and increased costs down the line. In many cases the result is legacy systems which are difficult to maintain and an overall negative Return on Investment.

Page 9

For your notes

© agil8


Project Variables

www.dsdm.org - DSDM Atern v2 - 2008


Waterfall Agile

WaterfallThe features to be delivered are fixed at the outset. Because the scope is fixed, if things do not go according to plan then the only option is to slip the timescale or assign additional resources to it (increasing costs) in order to deliver it on time. This approach is more suitable when the requirements are unlikely to change, the work is relatively simple, straight-forward and predictable and timescales and costs are not tightly constrained. Because the scope is fixed however, there is always the risk that quality will be compromised in the face of deadline and cost pressures.

AgileIn today’s world time is of the essence, timescales are often fixed and we are increasingly cost conscious. Moreover, it is now widely understood that increasing the number of people working on something does not give a commensurate increase in speed. Often it actually slows things down because of the communication overhead it introduces. Furthermore, in a fast paced, ever-changing world it does not make sense to fix a complete set of all features for delivery at the outset. Firstly not all features are equal. Prioritising and delivering a minimal solution first reduces time to market, gives earlier return on investment and yields early customer feedback which is particularly valuable when true customer needs are not that predictable. In addition, requirements are bound to change. We need to keep our options open to so closing options-off by fixing exactly what will be delivered right at the start and making it difficult to change doesn’t make sense. To deliver maximum return on investment when we trying to deliver something complex and unpredictable against fixed timescales and budgets we need to prioritize and put in place a way of working that create maximum transparency and opportunities for inspection and adaptation so that we can change as quickly as possible when needed, at least possible cost.

Page 10© agil8





ScrumA 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

Scrum is a process framework that has been used to manage work on complex products since the early 1990s. Scrum is not a process, technique, or definitive method. 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 work techniques so that you can continuously improve the product, the team, and the working environment.

Uses of ScrumScrum was initially developed for managing and developing products. Starting in the early 1990s, Scrum has been used extensively, worldwide, to:

1. Research and identify viable markets, technologies, and product capabilities; 2. Develop products and enhancements; 3. Release products and enhancements, as frequently as many times per day; 4. Develop and sustain Cloud (online, secure, on-demand) and other operational

environments for product use; and,5. Sustain and renew products.

Page 11© agil8


The Scrum Framework

• Scrum Events– The Sprint– Sprint Planning Meeting– Daily Scrum– Sprint Review– Sprint Retrospective+ Continuous Product Backlog Refinement

• Scrum Artifacts– Product Backlog– Sprint Backlog– Potentially Shippable Product Increment

• Scrum Team Roles– Product Owner– Development Team– Scrum Master

• Scrum Values– Commitment– Focus– Openness– Respect– Courage


Scrum has been used to develop software, hardware, embedded software, networks of interacting function, autonomous vehicles, schools, government, marketing, managing the operation of organizations and almost everything we use in our daily lives, as individuals and societies.

As technology, market, and environmental complexities and their interactions have rapidly increased, Scrum’s utility in dealing with complexity is proven daily. Scrum proved especially effective in iterative and incremental knowledge transfer. Scrum is now widely used for products, services, and the management of the parent organization.

The essence of Scrum is a small team of people. The individual team is highly flexible and adaptive. These strengths continue operating in single, several, many, and networks of teams that develop, release, operate and sustain the work and work products of thousands of people. They collaborate and interoperate through sophisticated development architectures and target release environments. When the words “develop” and “development” are used in the Scrum Guide, they refer to complex work, such as those types identified above.

Components of the Scrum FrameworkThe 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 in The Scrum Guide http://www.scrumguides.org/ which is updated every so often.

Page 12© agil8


Scrum Process Diagram


SprintBacklog

ProductBacklog

PotentiallyReleasable

ProductIncrement

Sprint(max 1 month)

24hours

SprintPlanning

DailyScrum

SprintReview &

Retrospective

Page 13© agil8

For your notesYou created a picture of the Scrum Framework during your training. Why not take a photo of it, print it out and stick it into the space above with some notes about it?


The Sprint

• ‘Protected’ time-box: One month or less– Limit change– Limit complexity– Limit risk– Increase predictability

• Back to back• Consistent durations• Create a potentially releasable product Increment


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.

Sprint DurationEach 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.

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.

Page 14

For your notes

© agil8


Potentially ReleasableProduct Increment

• Deliver an Increment of functionality every Sprint• Each is additive to all prior Increments

– Integrated and thoroughly tested– Ensuring that all Increments work together

• Each Increment is useable– So Product Owner may choose to release it

• Thus each Increment is “potentially releasable”


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 in useable condition and meet the Scrum Team’s definition of “Done.” An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal. The increment must be in useable condition regardless of whether the Product Owner decides to release it.

The Importance of Agile Technical Engineering PracticesEach Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together. This means that each Sprint must include:

• Integration of any changes or new functionality with previous increments• Refactoring of the design of previous increments as necessary• Regression testing of previous increments

Thus, the amount of integration and regression testing will increase, quite dramatically, with each successive Sprint. If this integration and regression testing is a wholly or largely manual activity then it will become a significant overhead and the team will require longer Sprints or even be tempted to postpone it to a large waterfall-style single pass of integration and testing. This will significantly increase the risk profile of the future work. Use of XP agile software engineering practices such as continuous integration, refactoring and test automation are of great benefit here.

Page 15

For your notes

© agil8


The Significance of “Done”

• Must understand what “Done” means so as to– Assess when work on Increment is complete– Assess how many items to select during Sprint Planning

• “Definition of Done” varies between Scrum Teams• “Done” gradually expands to become more stringent• Ideally “Done” = “100% Done” or “Done, Done”• Have potentially releasable

functionality “Done” each SprintWhat is your “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.

Development Teams deliver an Increment of product functionality every Sprint. This Increment is useable, 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 organisation, all Scrum Teams must follow it as a minimum. If "done" for an increment is not a convention of the development organisation, 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.”

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.

Page 16

For your notes

© agil8


Example ‘DoD’ for Software


Activity (Example) Criteria (Example)

Detailed Analysis Acceptance Tests approved by Product Owner. Wiki updated.

Detailed Design Consistent with approved design patterns and UI standards. Design approved by Architect. Overall Design Doc updated.

Build & Unit Test Consistent with coding standards. Peer Reviewed. 90% automated unit test coverage. All unit tests passing.

Low-level Integration Integrated with team’s branch. Mocking/stubs used as needed.

That’s DONE!

Full Integration and System Test

Tests automated wherever possible, specified where not. Testing standards adhered to. All system tests passing.

Acceptance Test and Documentation

Acceptance tests executed and automated wherever possible. All acceptance tests passing. Documentation approved by PO.

Pre-ProductionDeployment

Deployed through standard production process onto shadow live environment behind firewall. Approved by Ops for release.

That’s DONE-DONE!

The Definition of Done above is fairly typical for a software team early on in its adoption of Scrum within a corporate environment. Constraints of their existing way of working mean they are unable to get Product Backlog Items 100% truly Done within a Sprint.

• Full system testing is impossible every Sprint, perhaps because it requires integration with the work of other teams or systems which are not set up for it.

• Acceptance testing by customers is not possible in every Sprint, perhaps because the customers are not willing or able to do it on a Sprint-by-Sprint basis.

• Finally, deployment by the team of their work into a production ready environment is not possible, perhaps because of a centralised release process that needs the involvement of a separate group.

This work can only be done at a later date, perhaps in a large batch, and sometimes even by another team. This increases the length of the overall feedback loop and increases the risk of late problems being discovered. This team should change the way that it works in order to gradually move the first dark blue line (“Done”) down until it coincides with the second (“Done Done”). This can take many months or even years to achieve in some organisations.

Page 17

For your notesWhat is your Definition of Done?

© agil8


Example ‘DoD’ for Training Materials

All to be completed in Sprint for each Product Backlog Item• Design

– Latest PPT and XLS templates used– Sections identified and Content Slides

created/updated as necessary for each– Timetable outlined in XLS

• Build– All components linked to Master

components on Slide Master(no “Hard Coding”)

– Good balance of white space– Max 7 main bullets of 7 main words on

a slide (excluding “a”, “of”, “the” etc.) – All slides to contain a hi-res graphic– All slides to have Notes

• Integration and Refactoring– No inconsistencies within materials– No inconsistencies between this and

other relevant materials• Review

– All content spelling & grammar checked– Content reviewed by at least one other

knowledgeable Trainer• Release

– Rendered into PDF accurately– Minimum number of files for Printing– Version control information correct– Saved into Training Team staging area


The Definition of Done does not define the customer’s requirements - the Product Backlog Items would do that e.g. the Requirement for a Product Owner Training class to include an example User Story might be expressed as follows:

Example Product Backlog Item in User Story FormatAs a delegate on Product Owner TrainingI want a good example and explanation of a typical “fully dressed” User Story (including Acceptance Criteria) that can be a subject of discussion within the training course and a point of future reference afterwardsSo that I have an improved ability to produce good quality User Stories. Acceptance Criteria:1. Is the example User Story one that any course delegate will understand?2. Does the example User Story contain the maximum desired density of information?3. Does the example User Story provoke thoughts about how negotiable it is?4. Does the example User Story provoke thoughts about how it could be Split?5. Does the example User Story have half-a-dozen or so example Acceptance Criteria?

Rather the Definition of Done ensures that each and every Product Backlog Item is “Done” properly to the correct level of Technical Quality with regard to the way it is designed, built, integrated with earlier work, reviewed and released for possible use and reuse. In order to be considered “Done” at the end of a Sprint, work on the Product Backlog Item must have be completed as per the “Definition of Done”.

Page 18

For your notesWhat is your Definition of Done?

© agil8


Change During the Sprint

• No changes allowed thatendanger Sprint Goal

• Scope may be clarified andre-negotiated during Sprint– Product Owner cannot force

it onto Development Team

• Team composition remains constant• Quality goals do not decrease


Production IssuesWhere a team is subject to urgent production issues, they either plan sufficient spare capacity into each Sprint to cater for them; or agree a policy with their Product Owner which recognises that only critical issues should be allowed into a Sprint after it has started. The policy should be designed to make the impact of the unplanned work transparent to stakeholders.

Scrum and Kanban together: ScrumBanTeams that are working in a very reactive environment (e.g. support and maintenance teams) sometimes find that there is little point in doing Sprint Planning at all as they cannot plan and agree the Goal or the work of the Sprint in advance. Such teams often use a combination of Scrum and Kanban (sometimes referred to as “ScrumBan”) where they do everything that Scrum mandates except Sprint Planning. Instead of Sprint Planning they simply pull items into the Sprint from their highly volatile changing Product Backlog, when they have capacity to do so. How they select items and how many they have in progress at one time are typically governed by explicit policies.

Page 19

For your notes

© agil8


Cancelling a Sprint

• Very uncommon to cancel a Sprint• Only Product Owner can do it• Only if Sprint Goal becomes obsolete

– e.g. company changes direction;market / technologyconditions change

• Cancellation rarely makes sense• Stop, review, retrospective, re-plan


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 market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given circumstances. But, due to the short duration of Sprints, cancellation rarely makes sense.

Implications of Sprint CancellationWhen a Sprint is cancelled, any “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.

Page 20

For your notes

© agil8


The Scrum Team• Cross-functional

– All skills needed to accomplish the work– Minimise dependencies outside the team

• Self-organising– Choose how to accomplish their work– Not directed by others outside the team

• Scrum Team roles– Product Owner:

owns the Product Backlog – Development Team:

owns the Sprint Backlog– ScrumMaster: Facilitates


The Scrum Team consists of a Product Owner, the Development Team, and a ScrumMaster. Scrum Teams are self-organising and cross-functional. Self-organising 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 optimise flexibility, creativity, and productivity.

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

Page 21

For your notes

© agil8





The Product Backlog is the most important artifact in Scrum. It 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.

User StoriesProduct Backlog Items are often expressed as User Stories but this is not mandated by Scrum. User Stories, originally part of XP, are a very effective way of understanding customer requirements. The technique consists of summarising each User requirement with a statement of “As a” … “I want” … “So that” with unambiguous Acceptance Criteria. This summary is elaborated through conversation between the Product Owner, relevant stakeholders and members of the Development Team.

The Product Backlog is AliveA Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements. It then 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.

Page 22

For your notes

© agil8


Product Backlog

• Ordered and estimated list– Ordered by value, size, risk, dependencies

• Covers everything that might be needed– Features, requirements, enhancements, fixes

• Never complete, baselined or “signed-off”– Evolves as circumstances evolve

• Each item has a description. Often “User Stories”– Those at top broken down more

• Owned by the Product Owner


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 artifact. Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog.

Multiple Teams or Multiple ProductsMultiple 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.

Where a single Team is responsible for more than one Product they should have one Product Backlog which identified which Product each Item is for, and one product Owner who is accountable for the Product Backlog.

Page 23

For your notes

© agil8


Next sprint

Sizing PBIs Appropriately

Next release Future releases


Must be small enough to easily be done in SprintAim for 1-5 days effort to get each PBI ‘Done’Take many PBIs into each Sprint

Product Backlog Items should not all be defined in detail up-front. It would take far too long and requirements and desired features are likely to change anyway. If they are not going to be delivered for many months, more, or maybe never, they should only be defined in outline as large pieces of functionality (often referred to as “Epic” Stories).

Breaking Big Product Backlog Items DownThose Product Backlog Items that are planned for delivery in the next few Sprints should be broken down and defined in more detail, and those which are likely to come into the very next Sprint should be broken down smallest of all : ideally so that they are between 1 and 5 days of effort each to get “Done”(with experience a team will soon understand roughly how many Story Points this equates to – but they should still do their Story Point estimating by comparing the relative size of their Stories rather than thinking in terms of days).

Breaking the Product Backlog Items down small will help ensure that the team understands them well, that their estimates are more accurate, that their testing is simpler, and hence the quality will be better. Smaller Product Backlog Items are more likely to get “Done” within a Sprint. Larger Stories are more likely to spill over into the next Sprint. Slightly bigger than 5 days may not be a problem but if Stories are 10 or 15 days of effort each then problems with getting them Done are much more likely.

Page 24

For your notes

© agil8


Product Backlog Refinement

• Updating Product Backlog - aka ‘Grooming’– Focused primarily on PBIs due for development– But also the rest of the Product Backlog beyond– Product Backlog order, estimates, splitting, more detail etc.

• Ongoing process between Product Owner and Development Team– Usually 5-10% of Development Team’s time during Sprint

• How and when decided by Scrum Team– e.g. Refinement meeting in second half of Sprint


SprintPlanning

SprintReview andRetrospective

Refinement

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. Product Backlog Refinement is often focused around a meeting. However, Product Backlog items can be updated at any time at the Product Owner’s discretion.

Getting Product Backlog Items Ready for DevelopmentHigher 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.

Estimating Product Backlog ItemsProduct Backlog Items are estimated before the first Sprint when the initial Product Backlog is created, and during Product Backlog Refinement in each Sprint.

Page 25© agil8


Estimating Product Backlog Items

• T-Shirt sizing – small / medium / large / XL / XXL– Quick and easy – often used for ‘Epic’ Stories– Non-numeric: can’t be used to track Velocity

• Ideal Days – pure effort without overhead– Tends to draw you into detailed task estimates– Can take too long to do

• Story Points – most popular– Quick and easy to do – purely relative– Removes disparity of different skill levels


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. Scrum does not recommend any particular estimating approach but most Teams use relative Story Points and Planning Poker or some variation such as “Affinity” or “Magic” estimating.

Estimating in Relative Story Points vs Estimating in Days or Ideal DaysStory Points have several advantages over estimating in days:1. People are much better at comparing the relative size of things than they are at

making an absolute estimate in days2. Development Team members with different skill levels who would get through work

at different speeds are more able to agree on an estimate with Story Points3. Relative Story Point estimation is quicker because it avoids the tendency to do task-

breakdown which comes with estimating in days4. Story Point estimates are less likely to need to be changed if the team changes its

development approach (e.g. by introducing more automated testing)5. An estimate in days is more likely to be interpreted as a fixed delivery date by

stakeholders than a Story Point estimate. This can put the quality of the deliverable, and hence the potential return on investment, at risk.

T-Shirt SizingT-shirt sizing is used by some Scrum Teams, particularly for initial estimating of large Product Backlog Items (“Epic Stories”) but they have to resort to a points-based approach in order to compare items and to understand what their velocity is.

Page 26© agil8


Velocity

• How much work can a team get ‘Done’ in a Sprint?• Track over time from one Sprint to the next• Not comparable between teams!


Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7

PointsDone

At the end of the Sprint the Team’s “Velocity” can be calculated by adding-up the estimates for those items that have reached “Done”. Velocity is usually measured in Story Points. Teams that consistently break all of their Product Backlog Items down to a similar size can simply count the number of Items “Done” instead. Those Teams that estimate in Ideal Days calculate their Velocity as the number of Ideal Days worth of work they completed in the Sprint (e.g. though we had had 56 man days capacity in the sprint and got 50 Ideal Days of work done).

Use Original Estimate or Re-estimate of incomplete Items? Any Items that are not quite “Done” can be assessed, their remaining work re-estimated and taken in to a later Sprint. The question often comes up whether the original estimate or the re-estimate should be used to calculate the velocity once they are Done? Velocity will ebb-and-flow no matter which approach is taken. The simplest and most popular approach is to use the original estimate.

Using Historic Velocity to Inform Forward PlanningOn an empirical basis, a Scrum Team’s Velocity measured over a number of Sprints can be a useful guide to how much work they are likely to complete over future Sprints. Data used has to be relevant: Velocity 3 years ago for example is unlikely to be relevant. Some teams use historic Velocity data during Sprint Planning to determine how much work they should take into a Sprint. However, most teams find that historical Velocity is generally a better indicator for medium and long-term Product Road Map or Release Planning than for short-term Sprint Planning. In Sprint Planning, most teams break their Product Backlog Items down into Tasks and estimate those Tasks in hours in order to determine how much they think they can get done. Irrespective of how it is used, Velocity figures cannot be used to compare teams. Nor can Velocity be used as a measure or predictor of the productivity of individual people.

Page 27© agil8


Monitoring Progress AgainstProduct Backlog

• All information made transparent to all stakeholders • Total work remaining can be summed at any time

– PO tracks work remaining at each Sprint Review– Compares with work remaining at previous Sprint Reviews

• Projections madeto forecast progress

• Forward decisionsbased on empiricalmeasurement


0

50

100

150

200

250

1 2 3 5 6 7

LatestPlanned

At any point in time, the total work remaining 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. 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.

Page 28

For your notes

© agil8





The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organising and cross-functional. Self-organising 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 optimise flexibility, creativity, and productivity.

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

Page 29

For your notes

© agil8


Scrum Values

• Commitment• Focus• Openness• Respect• Courage

See Scrum Alliance Code of Ethicshttp://www.scrumalliance.org/code-of-ethics


When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone. The Scrum Team members learn and explore those values as they work with the Scrum events, roles and artifacts.

Scrum is more than a set of Roles, Events and ArtifactsSuccessful use of Scrum depends on people becoming more proficient in living these five values. People personally commit to achieving the goals of the Scrum Team. The Scrum Team members have courage to do the right thing and work on tough problems. Everyone focuses on the work of the Sprint and the goals of the Scrum Team. The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work. Scrum Team members respect each other to be capable, independent people. The values of the wider organisational context within which the team work will have an impact on the degree of success with Scrum.

Page 30

For your notes

© agil8


Product Owner Responsibilities • Drives Product Success

– Up-to-date knowledge of customer need• Creates and communicates Product vision

– Clear goal, motivates quality work• Creates and maintains Product Backlog

– Regularly updated as new information emerges• Collaborates with Scrum Team and other Stakeholders

– Understand requirements and identify how to solve them• Participates in Sprint meetings

– Must participate in Sprint Planning, Review and Retro– May participate in Daily Scrum


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

Page 31

For your notesWhat are the characteristics of a good Product Owner?

© agil8


Product OwnerProduct Backlog Responsibilities

• Ordering Product Backlog to best achieve goals• Clearly expressing Product Backlog items• Ensuring it is transparent• Ensuring it is always up to date• Ensuring Development Team understand it• Ensuring their work has max. value• May delegate parts of this to Development Team

– But Product Owner remains accountable


The Product Owner is the sole person accountable 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; • Optimising 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.

Page 32

For your notesWhat risks may there be in delegating Product Backlog management?

© agil8


Product Owner Practicalities

Authority• Product Backlog Items & order• When releases are made

– Without over-ruling Development Team’s estimate

• Entire organization must respect PO’s decisions– No one else allowed

to direct Development Team– Development Team

must not act onothers’ directions

Constraints • One single Product Owner

– May represent aCommittee of Stakeholders

– Stakeholders mustconvince Product Owner

– May have sub-POs for areas of a large product

• Organisational Respect– Authority to make decisions

needed to achieve RO


ConstraintsThe 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.

AuthorityFor the Product Owner to succeed, the entire organisation 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.

Page 33

For your notes

© agil8


Scrum Master Authority

• Largely indirect: a “servant leader”• Springs mainly from deep knowledge of Scrum

principles and practices• No authority to make

decisions for the Team• Cannot commit to dates

of delivery or scope• May enforce Scrum process


The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.

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.

Page 34

For your notesWhat are the characteristics of a good Scrum Master?

© agil8


Scrum Master Responsibilities • Process-Related Responsibilities

– Implements Scrum Framework– Coaches people on various roles

• Serves the Scrum Team– Assists, facilitates creativity, fosters

empowerment – Removes “impediments”

• Coaches the Scrum Team– To improve productivity, working

practices and tools

• Protects the Scrum Team– Shields from interference– Helps ensure organisation respects

commitment of Team

• Guides the Scrum Team– Models values of Agile & Scrum– Encourages Team to challenge

themselves

• Acts as a Change Agent– Promotes learning points


Scrum Master Service to the Product Owner • Ensuring that goals, scope, and product domain are understood by everyone on the

Scrum Team as well as possible;• Finding techniques for effective Product Backlog management;• Helping the Scrum Team understand the need for clear and concise Product Backlog

items;• Understanding product planning in an empirical environment;• Ensuring the Product Owner knows how to arrange the Product Backlog to maximize

value;• Understanding and practicing agility; and,• Facilitating Scrum events as requested or needed.Scrum Master Service to the Development Team • Coaching the Development Team in self-organisation 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 organisational environments in which Scrum is not

yet fully adopted and understood. Scrum Master Service to the Organisation• Leading and coaching the organisation in its Scrum adoption; • Planning Scrum implementations within the organisation; • 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 organisation.

Page 35© agil8


Development Team• Between 3 and 9 Development Team members

– Small enough to be nimble– Large enough to complete significant work

• Product Owner and ScrumMaster not included– Unless doing work on Sprint Backlog

• Co-located– or appropriate measures taken

• Full-time– or predictable availability if not


http://www.oeinstitute.org/articles/improving-patient-care.html

Development Team SizeOptimal 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.

Co-location and Full-time AvailabilityScrum does not mandate co-location or 100% dedication to the team but the impact must be considered if it is not possible. Communication and team dynamics are more difficult with distributed teams and team members who are only part time or belong to multiple Scrum Teams will be less well integrated with the other team members and may find participation in the Sprint Meetings challenging. The ScrumMaster should teach the Scrum Team to take steps to mitigate these effects where possible.

Page 36

For your notes

© agil8


Cross Functional & Self Organising

• Self-organising to get the work “Done”• Cross-functional with all skills to create Increment• Feature teams not component teams• No specialist sub-teams (e.g. testing, BA)• Members known as Developers• Individuals may have

specialized focus• Accountability belongs to

Development Team as a whole


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

• They are self-organising. 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 recognises 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 recognises 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 specialised skills and areas of focus, but accountability belongs to the Development Team as a whole.

Page 37

For your notes

© agil8


Development Team Responsibilities

• Self-Organizes with “whole team accountability”– No appointed Leader. Team success over individual– This takes time and patience. Scrum Master must guide

• Creates potentially releasable Increment every Sprint– Implications for Team composition and collaboration

• Creates & maintains Sprint Backlog to track progress• Collaborates to achieve goal of Sprint …• … and goal of each Sprint meeting


The Development Team consists of those 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, and it must include within it all of the skills required to get the Increment “Done”. Individual members may have specific skills and areas of focus, but everyone is known as a Developer and accountability belongs to the Development Team as a whole. Rather than having one appointed Leader who exercises leaderships in all things, rather leadership should be a responsibility which can be undertaken by different members of the team at different times dependent upon their skills and experience and the tasks at hand.

Page 38

For your notes

© agil8





Prescribed events are used in Scrum to create regularity and to minimise 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.

Page 39

For your notes

© agil8


Sprint Planning Meeting

• Meeting to plan the work in the Sprint• Plan is created by entire Scrum Team• Time-boxed – 8hrs for 1 month Sprint

– Proportionately less for shorter Sprints

• Meeting in two parts– Each half of overall duration– 1: What will be delivered?– 2: How will it be achieved?


The work to be performed in the Sprint is planned at the Sprint Planning meeting. 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.

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

Page 40

For your notes

© agil8


Sprint Planning Part OneWhat will be Done this Sprint?

• Input to this meeting– Review of product Increment– Up to date Product Backlog– Past performance of Development Team– Projected capacity/performance during Sprint

• PO presents the ordered Product Backlog items• Entire Scrum Team collaborates to understand work required• Development Team forecasts what can be delivered from the Sprint• Number of items selected is up to Development Team• Entire Scrum Team crafts Sprint Goal


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 to understand the work.

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.

Page 41

For your notes

© agil8


Sprint Goal

• Short statement of objective of the Sprint• Guidance on why the Increment is being built• Gives Development Team some flexibility on functionality• As the Development Team works, it keeps goal in mind• If work required is different than expected

– Development Team and ProductOwner negotiate scope

– Quality is not compromised• Sprint Goal may be a product

roadmap milestone


The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog Items. It provides guidance to the Development Team on why it is building the Increment. It is created during Sprint Planning.

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 the Sprint Backlog within the Sprint.

Page 42

For your notes

© agil8


Sprint Planning Part TwoHow will the chosen work get Done?

• Development Team plans work to get PBIs “Done”• Tasks may be of varying size

– Enough detail to forecast what can be “Done”– First days often decomposed to Tasks of one day or less– Further work may be planned in detail later,

usually after each Daily Scrum• Scrum Master facilitates• PO may be present during Sprint Planning Part 2

– To clarify and help make trade-offs– To renegotiate if Development Team has too much / little work

• Others may be invited to provide advice© agil8 - ScrumMaster Training v5.1 43

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-organises 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-organising team to accomplish the Sprint Goal and create the anticipated Increment.

Page 43© agil8


Sprint Backlog

• Forecast PBIs that will be delivered in next Increment• An emerging plan for work needed to get them “Done”• Initial Tasks often detailed in Sprint Planning

– Later work planned in outline– More detailed planning is done during the Sprint

• Visible to all, kept up-to-date every day– Tasks added / removed as they become understood – Estimates to complete revised

• Owned by Development Team– Only they can change it


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 the work that the Development Team identifies as necessary to meet the Sprint Goal. To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting.

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.

Page 44

For your notes

© agil8


Monitoring Sprint Progress

• Work remaining can be summed any time• Development Team tracks progress to consider

during each Daily Scrum– To assess likelihood

of achieving Sprint Goal– In order to manage

its progress


0

50

100

150

200

250

300

Wed Thu Fri Mon Tue Wed Thu Fri Mon Tue

Planned

Latest

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 progress.

Page 45

For your notes

© agil8


Example Big Visible Charts


Scrum relies on transparency. Decisions to optimise 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. Big visible charts, also known as “Information Radiators” are valuable in promoting transparency.

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 organisation to increase the transparency of the artifacts. This work usually involves learning, convincing, and change. Transparency doesn’t occur overnight, but is a path.

Page 46

For your notes

© agil8


Daily Scrum Meeting • 15-minute time-box, same time and place each day• Not a status reporting meeting• Synchronize and create plan for next 24 hours• Development Team assesses progress toward Sprint Goal• Benefits of Daily Scrums

– Eliminate other meetings– Identify and remove impediments– Promote quick decision-making– Foster sense of “team commitment”– Improve communications and knowledge

• Optimises probability of meeting Sprint Goal© agil8 - ScrumMaster Training v5.1 47

The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work. The Daily Scrum is held at the same time and place each day to reduce complexity.

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.

Page 47

For your notes

© agil8


Daily Scrums In Practice• Scrum Master ensures that Daily Scrum happens

– Development Team is responsible for doing it• Whole Development Team participates

– PO may also, but no-one else

• Three questions:– What has been accomplished since last meeting? – What will be accomplished before next meeting? – What obstacles are in the way?

• Complex issues are taken off-line© agil8 - ScrumMaster Training v5.1 48

The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal. Some Development Teams will use questions, some will be more discussion based. Here is an example of what might be used

• 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 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 Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.

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.

Page 48© agil8


Sprint Review Meeting

• Informal meeting to elicit feedback and collaboration• Inspect Increment, adapt Product Backlog if needed• What was done in the Sprint?• What should be done in the future Sprints?• Timeboxed

– 4hrs for 1 month Sprint– Proportionately less for

shorter Sprints


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 optimise 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 at most a four-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendees understand its purpose. The Scrum Master teaches everyone involved to keep it within the time- box.

Page 49

For your notes

© agil8


Sprint Review in Practice

• Product Owner identifies what is“Done” and what is not “Done”

• Team discusses how Sprint went• Team demos work “Done”• Product Owner discusses Product

Backlog and likely completion dates• Entire group discusses what to do next

• Result is probable items identified for future Sprints• Product Backlog must be adjusted accordingly


• Attendees are the Scrum Team and 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 is a revised Product Backlog that has been adjusted to meet new opportunities and defines the probable Product Backlog items for the next Sprint.

Page 50

For your notes

© agil8


Sprint Retrospective Meeting

• After Sprint Review, prior to next Sprint Planning Meeting• Scrum Team inspects itself and creates improvement plan• Timeboxed

– 3hrs for 1 month Sprint– Proportionately less for shorter Sprints

• How last Sprint went?– People, relationships, process, tools– Identify & order potential improvements– Create improvement plan– Update Definition of Done as necessary

• Larger Retrospectives can be held after each Release


Things that did not go

well

Things that went well

Puzzles Bright Ideas

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

Timing of the Sprint RetrospectiveThe Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is at most a three-hour 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.

Page 51

For your notes

© agil8


Retrospectives in Practice

Prime DirectiveRegardless of what we discover, we understand and truly believe that everyone did the best job that they could, given what they knew at the time, their skills and abilities and the situation at handProject Retrospectives, Norman Kerth, 2001

ApproachCollective story telling at the end of some work to review the events and learn from the experiences• Set the scene• Gather data• Generate insights• Decide what to do• Close the RetrospectiveAgile Retrospectives, Derby & Larsen, 2006


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”.

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.

Page 52

For your notes

© agil8





Thank you for participating in this agil8 Training Course. We hope you have found it informative and enjoyable. At the back of this Course Notebook you will find a Feedback form which your Trainer will ask you complete. We are constantly inspecting and adapting the content and delivery of our courses and the administration around them. We would love to hear your verdict on how we did and how we might improve in future.

All that remains before we finish is to outline the the options that you have following this course and into the future, and to give you some pointers for next steps.

Thanks again.

Page 53

For your notes

© agil8


Next Steps• Further agil8 training

– Agile Leadership and Executive Briefings– Advanced ScrumMaster

and Product Owner– Large Scale Agile– Agile Analysis and Story Writing– Kanban– Certified Scrum Software Developer– Agile Coaching and Facilitation Skills

• Consulting, coaching and Agile transformation– Initiation, kickoff, planning, reviews, healthchecks


Page 54

For your notes

Further Agil8 TrainingAgil8 provides a full range of public and in-house training in support of your individual, team or organisational Agile transformation efforts. This includes Agile Leadership training and Executive Briefings, advanced ScrumMaster and Product Owner training, courses in all the leading Large Scale Agile Methods like SAFe and LeSS as well as more specific Deep Dive training on topics like User Stories, Kanban, Agile Software Engineering and Agile Coaching and Facilitation Skills.

Agil8 Consulting, Coaching and Agile Transformation ServicesTraining is an essential part of Agile adoption, but insufficient on its own without coaching and consulting from an expert Agile practitioner. Agil8 has a proven track record of helping teams and organisations large and small succeed with Agile.

© agil8


Further Reading• Some classic introductory books

– Agile Software Development with Scrum – Ken Schwaber– Agile Project Management with Scrum – Ken Schwaber– User Stories Applied – Mike Cohn– Project Retrospectives – Norman L Kerth– Extreme Programming Explained – Kent Beck– Peopleware – Tom DeMarco– Fearless Change – Linda Rising

• Portals– agil8 : www.agil8.com– Scrum : www.scrumalliance.org


If you put the words Agile and Scrum into Google, you will drown under a mass of information. To help you focus and get you started, above is a selection of the classic, original books about Agile that we believe should be found on every Agilist’s bookshelf.

Page 55

For your notes

© agil8


Keep In Touch

[email protected]

agil8 Community

@agil8er


Please do keep in touch with agil8 and let us know how you get on with Agile.

LinkedInWe have an online LinkedIn Community for agil8 customers, consultants and trainers, with thousands of members. We will send you a follow-up email after the training inviting you to join. Feel free to post any questions that you have about your use of Agile on the LinkedIn Group. Equally, feel free to contact your trainer. if you send any Agile-related questions directly to your trainer, they will post them and answer them on the LinkedIn group so that you can get a wide range of input from different people.

TwitterYou can also follow agil8 and your trainer through their own Twitter Accounts

EmailAgil8 and your trainer can also be contacted by email. Your trainer may not be able to respond immediately as they may be busy on client site, but give them a day or two and they will definitely get back to you.

Page 56

For your notes

© agil8


c ert i fi ed scru mm ast er - agil8 · + 44 (0) 207 796 9903 [email protected] c ert i fi ed...

Documents