Skip to main content

Scrum Glossary – INVEST

How do we know if a Product Backlog Item is of a good quality? We need to make sure it’s not too large to be implemented in a Sprint and that it can be tested in order to say that it’s Done.

To help us ensure a PBI is of good quality, we can use INVEST:

Independant – the PBI should be self-contained and not depend on other PBIs.

Negotiable – the PBI is not an explicit contract and should be open for discussion.

Valuable – it must deliver some form of value to the business

Estimable – the development team must be able to estimate how much effort it will take to implement the PBI.

Small – the PBI must fit within a Sprint.

Testable – we must be able to define tests/acceptance criteria for the PBI so that we know when it is Done.

Scrum Glossary – acceptance criteria

Acceptance criteria are used to define when a task is completed. They allow you to meet the Testable aspect of user stories when using INVEST.
They can cover both functional and non-functional criteria.

 

Example Acceptance Criteria

If we take the following as our user story:

As a registered user, I want to book onto a training course of my choice.

 

Some possible acceptance criteria could be:

  • Send confirmation email to user when booking is saved
  • Display correctly on PC, tablet and mobile phone.
  • The form cannot be submitted without entering all required data.

Acceptance criteria are specific to a user story, while the Definition of Done covers all stories.

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

What are the Roles in Scrum?

Scrum teams consist of a Product Owner, Scrum Master and the Development Team. Scrum teams are self-organising and cross functional.

Self-organising means that the team itself decides how to best complete the work, rather than being told by someone outside of the team.

Cross functional means the team has all the skills required to complete the work.

 

product ownerProduct Owner

The Product Owner (PO) is responsible for maximising the Return on Investment of the product development and this is usually done through the prioritisation of the Product Backlog Items.

The PO is the business contact for the team – they will liaise with stakeholders within the business to determine their desires for the product. However, only the PO can decide on the priority of these items.

The PO must also ensure that Product Backlog Items are clearly understood by the Development Team and has the final say on requirements decisions.

 

development teamDevelopment Team

The Development Team does the work to build a potentially shippable product increment every Sprint. They are self-organising, so only the team themselves decide how to create the increment.

They are also cross-functional so that the team has all the required skills to complete the work.

All members have the same title of Developer, so although members may have specialised skills, the team as a whole are responsible for all of the work.

Development Teams should have 3-9 members. Less than 3 makes it difficult to complete enough work within a Sprint, while more than 9 increases complexity.

 

scrum masterScrum Master

The Scrum Master is a servant-leader for the Scrum Team. They have a variety of responsibilities, which can be seen in full in the Scrum Guide, but the most important of these are:

  • They facilitate the work of the team by ensuring Scrum practices are understood and followed.
  • Protect the team from distractions such as stakeholders trying to sneakily get their feature worked on first.
  • Remove impediments.
  • Enforce time boxes.

The Scrum Master is not a Project Manager. A Project Manager runs the project and team, and is accountable to the business for completing that project. They may set work for team members, prioritise features and manage risk.
A Scrum Masters’ role is to facilititate the process and the team. Their accountability is to the Scrum process.

Scrum Glossary: Scrum

What is Scrum?

Simply put, Scrum is an Agile framework for developing complex products.

While it is often used for developing software, it can be used for any complex products, especially where requirements are not known or may change frequently.

Right at the start of a project we know less than we’ll ever know about the requirements. Scrum accepts this and doesn’t try to define all the requirements up front – like you would do in the Waterfall method. Instead, Scrum uses an empirical approach of Transparency, Inspection and Adaptation.

  • Transparency – the people involved in the Scrum process should be able to easily see the state of the process and the artifacts involved.
  • Inspection – looking at the process to determine what went well and what could be improved.
  • Adaptation – based on the results of Inspection, we make changes so that the Scrum process runs more smoothly next time. This way we are constantly and iteratively improving the process.

So requirements are discovered and refined as the project progresses.

Scrum aims to regularly release potentially shippable software increments using a series of meetings, with associated roles and artifacts.

We’ll look at these in more detail in subsequent posts, but the basic process is as follows:

 

Scrum process diagram

 

  1. The Product Owner creates a prioritised list of product features they’d like. This is called the Product Backlog.
  2. At the Sprint Planning meeting, the team takes a selection of these features from the top of the list to create the Sprint Backlog.
  3. These features are what they think can be completed during a Sprint – a 2-4 week period of development.
  4. The Development Team works to create the product increment.
  5. The team meets daily at the daily Scrum, where they report on progress.
  6. The Scrum Master helps to coach the team in the whole process, while removing impediments that they may encounter.
  7. At the end of the Sprint, the work we have completed so far should be potentially shippable I.e. Released to customers.
  8. Following this, the Sprint Review meeting allows the Stakeholders to view what was completed during the Sprint and for the team to discuss any issues they had. It also enables the Product Backlog to discussed.
  9. The Sprint Retrospective meeting allows the team to Inspect the Sprint to identify any issues and what can be improved.
  10. Backlog Refinement isn’t an ‘official’ Scrum meeting, but many teams find it useful. It ensures the Product Backlog accurately reflects the Product Owners needs by removing, creating and prioritising User Stories.