Skip to main content

Inspecting the changes to the Scrum Guide – November 2017

scrum guide 2017

In the true spirit of Scrum, the Scrum Guide itself is regularly inspected and adapted. Below I look at the changes that were added in the November 2017 update.

View a summary of the Scrum Guide changes.

 

Uses of Scrum

Read the Uses of Scrum section of the Scrum Guide

Scrum isn’t just for software projects; it can be used for any situation where the requirements are complex and uncertain: it has been used to develop “software, hardware…schools, government…”.

This addition can help promote Scrum in organisations that might not think it’s suitable for them.

 

The role of the Scrum Master

Read the Role of the Scrum Master section in the Scrum Guide

Previously the language used in the description of the Scrum Master often caused it to be seen as an enforcer of rules. The guide has now changed so that rather than ensuring team members adhere to Scrum theory and rules, Scrum Masters help members understand Scrum theory, rules and values.scrum master

By including an understanding of the Scrum values, it gives team members a more holistic view of Scrum, rather than simply following the rules, which can be an important step in promoting self-organisation.

There is also a line added in the section 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.”

Generally, the goals, scope and product domain are areas of expertise for the Product Owner. But perhaps they have difficulty conveying this information to the rest of the team. The Scrum Master can assist with this, possibly looking at the best techniques to achieve this.

 

The Daily Scrum meeting

Read the Daily Scrum section of the Scrum Guide

The Daily Scrum is an opportunity to inspect progress towards the Sprint Goal and to inspect progress in completing work from the Sprint Backlog. Previous versions of the Guide prescribed three questions that development team members should answer in every Daily Scrum:

What did I do yesterday?Daily Scrum

What will I do today?

Do I face any impediments?

 

However, this has often led to the meeting turning into a status update, rather than an opportunity to both inspect and adapt.

The Scrum Guide now allows teams more flexibility around how they run their Daily Scrum meeting. They may choose to use the three questions, which are given as an example, or they may prefer a more discussion based format. Whatever is decided, the Development Team sets the structure.

 

The updates also provide clarification about who can attend the Daily Scrum. I think that previously, use of the word ‘participate’ confused matters and people were unsure about who could attend the meeting and who could speak in it.

2016 version: “The Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum.”

2017 version: “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.”

Now it’s clear that it is up to the Development Team who can attend the meeting. If a third party is allowed into the meeting, they may speak and contribute as long as they don’t cause disruption.

 

Sprint Backlog

Read the Sprint Backlog section of the Scrum Guide

“To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting.”

This is probably something that most Scrum teams are doing already – in your Sprint Retrospective, identify how the Scrum process can be improved. Any improvements identified are then listed as a backlog item in the subsequent Sprint, ensuring that any identified improvements are implemented.

This ensures that improvements aren’t forgotten once the Retrospective has finished. The identified changes are fully transparent in the Sprint Backlog, ensuring their progress can be tracked.

 

 

Other minor changes

Timeboxes

The wording around timeboxes has been clarified to ensure that teams know they are maximum length for a meeting, but can also be shorter.

 

Product Backlog

Read the Product Backlog section of the Scrum Guide

2016 version: “The Product Backlog is an ordered list of everything that might be needed in the product”

2017 version: “The Product Backlog is an ordered list of everything that is known to be needed in the product”

This change makes a lot of sense and I’m surprised that it hasn’t been pointed out in the revisions document. We never fully know everything that might be needed in a product, so how can it be added to the Backlog? The update means the Backlog is a list of everything we know is required – as the team releases increments and obtains feedback, they will uncover additional features that are wanted. As they are discovered, the items are added to the Product Backlog.

 

Definition of Done

Read the Definition of Done section of the Scrum Guide

A new line has been added about how an expanded Definition of Done may cause increments that were previously Done, to no longer be Done, because they don’t meet the new expanded Definition of Done.

“New definitions, as used, may uncover work to be done in previously “Done” increments.”

I’m curious as to how this should be handled. Should the Product Backlog Items from the existing increment be re-added to the Backlog so they can be inspected and adapted to meet the new Definition of Done?

 

 

Conclusion

What are your thoughts on the changes to the Scrum Guide? Do they help to clarify things, or do they make the guide too prescriptive? Let me know in the comments below.

5 ways to be a great Scrum Master

Even the best Scrum Masters can often find ways to improve themselves, the team and the product. Below are a few tips that might help you become a better Scrum Master. Let me know in the comments what you think of these tips and feel free to add your own.

Listen to understand, not to reply

listen
Listen, Understand, Act by Steven Shorrock / CC BY-NC-SA 2.0

Most people do not listen with the intent to understand; they listen with the intent to reply

– Stephen R Covey.

 

Most people only listen to others so that they can respond and get their own point across. This doesn’t allow the speaker to be truly understood, which might be vital to solving their problem or helping them. To be a true servant leader Scrum Master, you must put your own priorities at the bottom of the queue when listening to a team member. Only when you have fully understood someone’s issue, can you begin to help them.

 

Check in not just to find out about progress, but to become aware of impediments so they can be removed.

A great Scrum Master can check in with staff to get a progress update, without micro managing them. While getting an update of progress is fine, go further by offering to remove any impediments that may exist.

 

Celebrate and showcase the team’s success

A great Scrum Master ensures that the whole organisation knows about the team’s successes and the effort that was required by them to achieve that success. This not only motivates the team, but it also highlights the benefits of Scrum to the organisation. This is especially useful where the organisation has just started its agile journey and is expecting to see the benefits of it.

As Scrum Master, remember that you helped the team achieve their success, but they achieved it.

 

Get out and about to remove impediments

It’s easy for people to ignore the emails you send to them, but it’s more difficult to ignore you when you’re stood right next to their desk. When you need to remove an impediment, sometimes it can be more effective to go and see someone in person. Not only should you get a more prompt answer, but you’ll get an insight into their situation – perhaps they are facing an issue which in turn means that they can’t help with your issue.

 

sailboatHave a variety of Retrospective techniques

To ensure that Scrum Retrospectives don’t get stale, it’s important for the Scrum Master to have a variety of techniques/formats for conducting this meeting. Whether it’s Start, Stop and Continue; the Sailboat or something a little different such as Lego models or the Constellation Game, having a variety of formats not only keeps the Retrospective fun and engaging, but also provides opportunities for all team members to express their views.

How to pass the Professional Scrum Master (PSM I) exam

scrum training seriesScrum Training Series videos

When I first started fulfilling a Scrum Master duty, I found the video training series by Michael James to be a great resource. The videos add a visual element that you don’t get with the Scrum Guide, and really help you picture the activities of a real-life Scrum team. Also, depending on your learning style, you might prefer to learn by watching videos, rather than reading text.

The mini tests at the end of each chapter are a great way to check your knowledge.

Scrum Training Series

 

scrum guideThe official Scrum Guide

Following a general introduction to Scrum through the above training series, you really need to get an understanding of the official Scrum Guide. You’ll likely need to read it quite a few times to ensure you understand and remember it. Although the PSM exam is open book, the time limit means that you won’t have the opportunity to look through the Scrum Guide for an answer.

How you best learn the Scrum Guide depends on your preferred learning style. Perhaps you just want to read the Guide over a few times, or write down its points on paper to help you remember. I used the two methods above, in conjunction with the audio book version: Scrum Guide Audio Book.

This allowed me to concentrate on the words of the guide while blocking out any distractions.

 

Additional Learning – Nexus

Nexus is the Scrum.org version of scaled Scrum. You may get one or two questions on your exam about Nexus (as the questions selected are randomised, you don’t know for sure if you’ll get any Nexus questions).

I recommend reading over the Nexus Guide to get a basic understanding of it.

 

Mock Exams

Once you have become more familiar with the Scrum Guide, it’s useful to try some practice tests. This gets you familiar with the format of the questions and how much time you have to answer them. The Scrum Open Assessment even features questions from the actual exam, so if you ensure that you can repeatedly score 100% on this text, you’ll be in a good position for the real thing.

A more extensive exam is the one created by Mikhail Lapsin: PSM I Quiz. This has the same number of questions and time limit as the real exam. Although the questions are not exactly the same as on the official exam, they are very close. This quiz also has a learning mode, where each question has an explanation – this is very useful for reaffirming your knowledge, or understanding why you got a question wrong.

 

The PSM I Exam

  • Have a copy of the Scrum Guide available in case you need to refer to it. However you’ll only have enough time to use it once or twice.
  • Make sure you read the questions properly. Often there may be a negative word in the question i.e. “Which of these is not…”
  • You should have enough time to go back and check your questions. If you finish early, make sure you do this.
  • You can flag any questions that you’re not sure about, to make it easier to return to them.
  • Make sure you answer all the questions, even if you’re not sure of which option to pick.

 

I hope this post has provided you with some useful resources and tips. Let me know how you get on with your PSM I exam, and Good Luck!

 

Scrum Artifacts and how to ensure transparency

Let’s look at the Artifacts involved in Scrum – items or objects that provide Transparency and allow us opportunities for Inspection and Adaptation.

Product Backlog

The Product Backlog is an ordered list of all the features that might be required in a product. The Product Owner is responsible for the content, ordering and availability of the backlog.

The Product Backlog is a living artifact, that is, it is never complete. Items are removed from the backlog when they are selected for a Sprint. Items can be added to the backlog at any time, but are most commonly added during Backlog Refinement.
Initially the backlog holds only the best known requirements, but as the product and its environment change, items are added to the backlog.

The items in the Product Backlog are ordered by their priority. Higher ordered backlog items are usually clearer and better understood than items lower down the list. As items increase in priority, they are refined so that the Development Team have a better understanding of them.

The Product Backlog is an information radiator – a large, easy to see, display of data that is accessible to all. It allows individuals to see the upcoming features for a product and liaise with the Product Owner if they think an important requirement is missing. However, only the Product Owner can add items to the backlog.

 

Sprint Backlog

The Sprint Backlog consists of the Product Backlog Items selected for the Sprint, plus a plan of how to turn those items into an Increment.

During Sprint Planning, the Development Team decides which items it can implement during the Sprint, and these items are selected for the Sprint Backlog. The Development Team then formulates a plan on how to complete the work.

sprint backlog

As more information becomes available during the Sprint, the Sprint Backlog may change, with new items being added or unneeded items being removed. The plan to implement the items may also change.

The Sprint Backlog is owned by the Development Team. Only they can decide how much work can be completed in a Sprint and only they can change the Sprint Backlog.

 

Increment

The Increment is all the Product Backlog Items that have been completed during the current Sprint, plus all of the previous Increments. The Increment is a “Done” piece of software functionality that is potentially releasable to the customer. It is the decision of the Product Owner if the Increment is actually released or not. The Increment should allow the Sprint Goal to be satisfied.

 

Artifact Transparency

So that artifacts can be inspected, they must be transparent. This allows decisions based on the state of the artifacts to be made in order to control risk and increase business value. If artifacts are not sufficiently transparent, then they cannot be successfully inspected and risks may increase, costs may rise and decisions can be made incorrectly.

A good level of transparency has been achieved when the state of an artifact allows it to be easily inspected. This can be achieved by creating an open and blameless culture and ensuring that all members of the Scrum team are easily accessible. Stakeholders should be able to easily visit the Development Team in their office, as long as this doesn’t negatively affect the work of the team e.g. by stakeholders trying to add work to the Sprint without the consent of the Product Owner.

The Scrum Master works to ensure that all artifacts have the required level of transparency. They can do this by inspecting the artifacts, looking for patterns and noting differences between expected and actual results. For example, a Cumulative Flow Diagram can show where backlog items have been stuck in progress, causing a bottleneck. However, if a Scrum Master is made aware of an impediment, but this isn’t reflected in the cumulative flow diagram, this can indicate that the progress of a backlog item hasn’t been updated i.e. the Sprint Backlog doesn’t have full transparency.

Alhmodeus / CC-BY-SA-3.0

 

Scrum Events – The Sprint Retrospective

The Sprint Retrospective allows the team to inspect itself and adapt the Scrum process for the next Sprint. The meeting is time-boxed to 3 hours and involves the whole Scrum team.

We look at how the last Sprint performed with regard to

  • People
  • Processes
  • Relationships
  • Tools

We also identify what went well and what could be improved. This items can also be ordered in terms of importance.

Finally, the whole team collaborates to create a plan for the next Sprint. This details how the improvements that have been identified, will actually be implemented.

 

The role of the Scrum Master is to see how the Scrum process can be improved so that the team can fully benefit from it. They encourage the team to improve their development processes so that they are more effective in the next Sprint.

Using what we have learnt from the Sprint Review and Retrospective meetings, the team can adapt the Definition of Done. For example, perhaps a stakeholder who turned up to the Sprint Review was colour blind and the team had not tested for sufficient contract on text colours. The Definition of Done can be adapted to the include accessibility testing of the subsequent increment.

 

Although it is one of the shortest Scrum meetings, it is also one of the most important. It allows us to utilise the empiricism that Scrum offers, so every Sprint we have a formal opportunity to inspect and adapt.

In subsequent posts, we’ll look at some of the techniques that can be used during the Sprint Retrospective in order to facilitate discussion and learning.

Sprint Retrospective technique – Stop, Start and Continue

Here I’ll look at one of the practical techniques you can use to promote discussion and learning in your Sprint Retrospectives.

 

start stop continue

Start, Stop and Continue

In this technique, team members describe actions they think the team should Start, Stop and Continue doing.

Start items are those that the team haven’t done before but it seems likely they will be of benefit.
For example:

  • Show the software to the customer before the Sprint Review.
  • Ensure everyone has an equal amount of time to speak at the Daily Scrum meeting.
  • Include research time in PBI estimation.

 

Stop items are those which don’t add value or are inefficient.

  • Stop trying to use the latest, in fashion Javascript framework.
  • Don’t work on items that aren’t on the Sprint Backlog.

 

Continue items are those which we think have benefits, but haven’t yet become habit. Including them on the continue list gives us a reminder and ensure we do them in every Sprint.
Any of the previously identified Start/Stop items can go onto the Continue list. They are removed after a few Sprints, to ensure the list doesn’t get too long.

 

Selecting items

There are many ways in which the Scrum Master can ask for suggested items.

  • Simply allow team members to shout out the items.
  • Only allow particular items e.g. the Stop items.
  • Go round the team to ensure that everyone has the chance to put forward their ideas.

 

Voting

Once enough ideas are generated, the team should vote to determine which are the most important. This can take the form of each person voting for their highest priority item, or being allowed a certain number of vote e.g. 3, that they can assign to items as they wish.

 

The Subsequent Sprint Retrospective

At the next Retrospective it can be useful to bring along the list of items. The team can then determine if they have been effective in starting, stopping or continuing the items that were given the highest priority.

 

Conclusion

The Start, Stop and Continue technique is an easy way to generate actions during a Retrospective. It’s easy to grasp and you don’t need any special tools or software (although a physical board for displaying items on is helpful).

The Agile Manifesto

In February 2001, 17 individuals came together and wrote the Agile Manifesto, which says:
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:

  • Individuals and interactions over Processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

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

© 2001, the Agile Manifesto authors. This declaration may be freely copied in any form, but only in its entirety through this notice.

 

The Agile Manifesto in detail

But what does all of the above mean when it comes to carrying out Agile methodologies in practice? Let’s look at each point in turn – as our team use Scrum, that’s the framework that I will use for reference.

 

Individuals and Interactions over processes and tools

In Scrum, the team is all. They must work together to plan Sprints, estimate, do the work – the list goes on. There should be effective interaction both within the team and with individuals outside it so that the Scrum team can establish a good quality Sprint Goal and work towards it.
Regardless of who the interactions are between, the most important aspect is to ensure free flowing communication. This can be achieved by:

  • Creating a blame free culture
  • Ensuring individuals are able to speak up (see planning poker and silent writing)

 

Working software over comprehensive documentation

The aim of each Sprint is to produce a working increment of potentially shippable product. Agile values an increment of working software over large amounts of documentation which likely provide no business value.

documentation
Comprehensively planning and documenting user requirements don’t give you anything of business value. It’s only when an increment is developed, that we get a return on investment.

However, we still need to create documentation as long as it doesn’t interfere with the development of the increment. I would also say that user guides, for example, can create business value – without it, users may be unwilling to use your product.

 

Customer collaboration over contract negotiation

Only by collaborating with your customer can you understand what they want. You might think you know what they want, and you can even suggest this to them. But ultimately, you need to build a product that has the features they require.

This is even more important in Agile, where we focus on adding features that will add business value. The Product Owner (acting as a proxy for the customer) doesn’t want extraneous features adding, just because the development team thought it’d be cool. I’ve seen examples of this and it’s a perfect way to really annoy your customer.

collaboration

I would say that once you start to have an idea of requirements, this can be put into a contract. But the contract needs to allow for changing requirements. If we were doing Waterfall, the contract would be set in stone, alongside the requirements, at the start of the project.
But we’re doing Agile, we expect the requirements to change, so that contract needs to account for this.

The beauty of Agile is that the requirements will naturally emerge as the project progresses. The customer sees the increment during the Sprint Review and this allows them to feed back on what they like and what isn’t as they expected. This feedback is then used to adapt the increment in the next Sprint.

Underpinning all this is communication. If the developers aren’t sure what the customer wants, then ask the customer.  If you ask them straight away, you can prevent minor issues from growing into large problems.

 

Responding to change over following a plan

In the Waterfall model, we create detailed plans right at the start of the project. But this is the time when we’re least equipped to plan – we don’t know enough about what’s required from the product. Once you realise that change is required, it’s often too late.

plan

Agile accepts that requirements will change and emerge as the project progresses. We do plan in Scrum, but it’s a continuous process. By utilising relatively short timescales (the Sprint) we are offered more frequent opportunities to inspect the product and adapt it.

If a plan isn’t working, then why stick to it? Look at why it isn’t working (inspect) and change it (adapt) based on past experience.

We also ensure that we don’t plan too far ahead. If we plan too far in advance, by the time comes to implement the plan, the product and environment are likely to have changed, rendering the plan useless.

 

Conclusion

When working on a Scrum project, it’s important to try and keep the Agile Manifesto at the back of your mind. Think to yourself:

  • Are my interactions with others adding value or are they causing impediments?
  • Do we need this amount of documentation or can we take advantage of “Simplicity – the art of maximising the amount of work not done”
  • Are we effectively collaborating with the customer?
  • Is our plan working, and if not, why not? Are we able to inspect and adapt it? Are we planning too far ahead?

 

Read the original Agile Manifesto, and get translations, here.

Scrum Events – Sprint Planning

The development work that will be completed during the Sprint is planned at the Sprint Planning meeting and involves the whole Scrum Team.

If your Sprint is a month long, then the Sprint Planning is time-boxed to 8 hours. If you have a shorter sprint, then the time-box is reduced relatively.

 

sprint planning process

 

In Sprint Planning the aim is to essentially answer two questions:

  1. What will be delivered in the Sprint?
  2. How will we do it?

 

What will be delivered?

The Product Owner discusses what they’d like to achieve from the Sprint while the Development Team looks at which Product Backlog Items (PBIs) can be implemented in this Sprint.
Only the Development Team select the PBIs that will be worked on, as they know best what they can achieve.

The whole team collaborates to create the Sprint Goal – a high level objective that will be met when all the PBIs for this Sprit are implemented. The Sprint Goal provides guidance to the Development Team on why they’re building the Increment. It also gives the Development Team flexibility on how the Increment will be delivered – they commit to achieving the Sprint Goal, not the PBIs.

 

How will we do it?

The Development Team discusses how it will create the Increment.

Product Backlog Items + a plan for delivering them = Sprint Backlog

The Development Team will break down the PBIs into much smaller tasks, of around one days’ effort or less.
A plan for the whole Sprint doesn’t have to be created here – the team only needs to plan work for the first few days of the Sprint. The later work will be planned as the Sprint progresses.

The Development Team can discuss the PBIs with the Product Owner in order to clarify the requirements, and can renegotiate with him if they have too much or too little work.
They can also invite additional people in order to provide technical or domain knowledge.

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

 

When to estimate

I often see confusion around when PBIs should be estimated and each team does it differently. Some estimate PBIs and not tasks, some estimate both PBIs and tasks and others estimate tasks but not PBIs! Below is the way we do it, but remember to Inspect and Adapt to see which way is best for you.

  1. PBIs in the form of user stories are estimated in Story Points during the Backlog Refinement Meeting. This gives the Product Owner an additional metric to use when ordering the Product Backlog.
  2. As the PBIs are already estimated, when it comes to Sprint Planning, the Development Team can focus on selecting the appropriate items for the Sprint.
  3. Before we estimate the effort required, we define the acceptance criteria for a task. This ensures the Development Team knows what’s required to complete the task and allows them to more accurately estimate.
  4. Once the PBIs have been split into tasks during Sprint Planning, we then quickly estimate these tasks. At this point, many teams will switch to estimating in hours, but I don’t agree with switching metrics. So we again estimate in Story Points. Most of the time Development Teams members will be in agreement on the estimate for a task, but occasionally there will be a larger difference. This can be useful in highlighting technical issues that not everyone has thought of.
    As the team matures, it’s possible that they can do-away with estimating individual tasks.

We’ll look at the whole process of estimating, and the different techniques you can use to perform it, in a later post.

Scrum Events – The Sprint

Events in Scrum are used to create consistency and reduce the need for additional meetings that aren’t part of Scrum.
All events are time-boxed, so they have a maximum duration – the length of the time-box depends on the length of your Sprint.

The Sprint is essentially a container for all the other meetings and the development work. The other meetings provide opportunities to inspect and adapt the process.

 

 

Scrum process diagram

The Sprint

With a maximum time-box of one month, the Sprint is where the development work is completed, with the result being a “potentially shippable software increment”.

Potentially shippable means that the Product Owner may decide that the software can be released to the customer.
However, it doesn’t have to be released.

An increment is a small slice of software functionality, that can be added on to all the previously released increments.

But how do we know if the software is in a shippable state? That’s where “Done” comes in.

Scrum team members should have a shared understanding of what “Done” is, and this should also be shared between teams.

“Done” signifies when a Product Backlog item is complete.

 

Example Definition of Done

Each team will have its own definition, but here’s some examples of what you might include:

  • Code builds without errors
  • Code peer reviewed
  • Unit tests pass
  • User acceptance testing passed
  • Approved by Product Owner

As the Scrum Team progresses, it’s likely that the definition will become more strict.

 

The Sprint contains the Sprint Planning meeting, daily Scrums, development work, the Sprint Review and the Sprint Retrospective. There’s also the unofficial Backlog Refinement meeting which isn’t part of the Scrum Guide, but many teams find it useful to conduct.

No changes should be made during the Sprint that might endanger the Sprint Goal.

Sprint Goal

  • A high level objective for the Sprint that is met by implementing the Product Backlog Items.
  • The Team commits to the Sprint Goal rather than the PBIs.
  • The Sprint Goal provides guidance on why the Team are doing the work and allows flexibility around how the solution is achieved.

Also, quality goals should not decrease, although the scope of the sprint can be clarified and altered following discussion between the Product Owner and the Development Team.

Sprints last for a maximum of one month, but you may find it useful to use a shorter time-box. Shorter Sprints allow the team to more readily adapt to changing requirements, but make sure the Development Team has enough time to create software of value.

Shorter Sprints also reduce the risk if a Sprint is cancelled – the team has only ‘wasted’ the time in that Sprint and not any more. Additionally, they allow for more frequent inspection and adaptation, enabling the team to see more consistent progress towards a goal.

 

Cancelling a Sprint

Only the Product Owner has the authority to cancel a Sprint, but they can be influenced by stakeholders or the Development Team.
Cancellation usually occurs when the Sprint Goal becomes obsolete e.g. the feature is no longer required.

If the work that has been completed is in a shippable state, then the Product Owner can accept it. The rest of the work is put back into the Product Backlog.

 

A Sprint ends when the time-box expires and the following Sprint starts immediately (In practice this is usually the next working day).