Delivery

Build the current version of the design, to meet the ultimate goal

The delivery process model

Sprint planning

The aim of this meeting is to create the sprint backlog (a subset of the product backlog) and sprint goal. The delivery team plans the upcoming sprint. This meeting should be no more than 4 hours.

Outcomes:

  • talk through the ultimate goal for the project
  • talk through the user stories
  • developers will break each user story into tasks, giving estimates for each one
  • the product owner will sign off the priority order for the first sprint

After this meeting, the task list is set and there is no going back.

Daily scrum

These are 15 minute meetings at the same time every day that you are in a sprint. 3 topics are discussed to keep it short and sweet:

  • what did you do yesterday?
  • what will you do today?
  • do you have any blockers?

These are commitments that you are making as part of the self organising team

Sprint demo

There are only so many different ways to demonstrate a product but the key is not to go into the technicalities of how something has been done. We perfer to demo a product then and there instead of recording a demo and pressing play – so it is better to have all the right people in the same room. Nevertheless we are a digital team so we can look at including people on skype / appear.in or recording the demo for those who can’t attend.

A demo should follow a similar route each time:

  • create a story – use personas to guide the end to end process
  • plan what to do if something doesn’t work the way it should
  • be prepared for questions
Bashboard

Bashboard

Burndown

Burndown

Game changers

Game changers

How to run a demo

How to run a demo

Sprint retro

It is crucial for us to look at continually improving throughout the project we are working on. Retros styles will change depending on the team / project but the outcome is always the same. Blame is not the name of the game in a retro but you need to be open and honest if something isnt working as it should then say. Remember the good stuff is worth shouting about too!

4 emoticons

4 emoticons

5 dysfunctions of a team

5 dysfunctions of a team

Celebration grid

Celebration grid

Diamond or Charcoal?

Diamond or Charcoal?

Tech review

A chance to take a step back and look at what you have done through your peers eyes. Unlike the demo this is where you do look at the how and the why.

Tech reviews are not only for the benefit of those on the project team, for other team members its about knowing what’s being developed around you and making sure you keep up to date with the learning that comes from each project.

Service testing and refactoring

Service testing looks at what is in the test /UAT environment. Testing isn’t just about testing the process from end to end putting in all the correct answers, testers should be trying to break it. What happens if I do this…. What if I put in something completely random in this box instead of a date? Feeding back findings is the important bit – is it a bug (something that should work but doesn’t ) or is it a new feature that needs adding to the backlog?

Diary studies

Diary studies

Real user testing

Real user testing

Shadowing

Shadowing

Site visits

Site visits

Backlog refinement

Also known as backlog grooming the Scrum master / Business Analyst should be working with the PO to refine the backlog. This could be adding user stories to newly identified features or ensuring the backlog is in priority order (high to low) ready for the next sprint planning. Remember the PO owns the backlog so this needs to be completed together while keeping in mind TIME / COST / SCOPE of the project.

Release tasks

Once the sprint cycle has finished and you have received product sign off from your PO it is time to go through the release tasks. This is where the developers ensure everything is set up for the production environment and the Scrum Master ensures support processes are ready. There should be 3 days put aside for this at the end of the project before the day of release.

User feedback and testing

At the end of each sprint, we give a demonstration of the product to the service and any interested stakeholders. The demo should be no more than 2 hours.

The demo is usually followed by a retro (retrospective) where people are invited to share their thoughts on the team’s working practice, during the last sprint. The retro should take no more than 1.5 hours.

We also use this time to test what we have created with real users and stakeholdsers

Use the method cards below for more information on techniques and discussion points.

4 emoticons

4 emoticons

5 dysfunctions of a team

5 dysfunctions of a team

Agile coach/mentor

Agile coach/mentor

Backlog grooming

Backlog grooming

Bashboard

Bashboard

Benchmarking data

Benchmarking data

Budget / resource management

Budget / resource management

Building the product

Building the product

Burndown

Burndown

Celebration grid

Celebration grid

Create a concept

Create a concept

Customer surveys

Customer surveys

Daily stand up

Daily stand up

Decision making

Decision making

Diamond or Charcoal?

Diamond or Charcoal?

Diary studies

Diary studies

Draw the sprint

Draw the sprint

Embody 5 scrum values

Embody 5 scrum values

Environment building

Environment building

ESVP

ESVP

Game changers

Game changers

Glad, sad, mad and kudo

Glad, sad, mad and kudo

Health check

Health check

Heat maps

Heat maps

How do you feel?

How do you feel?

How might we…?

How might we…?

How satisfied are you about…

How satisfied are you about…

How to run a demo

How to run a demo

How to run a retro

How to run a retro

Idea workshop (6-8-5)

Idea workshop (6-8-5)

Identifying priorities

Identifying priorities

Improve cards

Improve cards

Interviews

Interviews

Journey mapping

Journey mapping

Lean coffee

Lean coffee

Lego

Lego

Lego!

Lego!

Liked, learned, lacked and longed for

Liked, learned, lacked and longed for

Load testing

Load testing

Looking back

Looking back

Loved, hated, learnt

Loved, hated, learnt

Mapping involvement

Mapping involvement

Milestones

Milestones

Mock ups and wireframes

Mock ups and wireframes

Monitoring progress / keeping the team accountable

Monitoring progress / keeping the team accountable

MVP (minimum viable product)

MVP (minimum viable product)

MVP realignment

MVP realignment

Next action

Next action

One word

One word

Pictionary

Pictionary

Prime directive

Prime directive

Protect the sprint backlog

Protect the sprint backlog

Prototype

Prototype

Radar

Radar

Real user testing

Real user testing

Research

Research

Risk management

Risk management

Scenarios and storyboarding

Scenarios and storyboarding

Seasons

Seasons

Shadowing

Shadowing

Share observations

Share observations

Site visits

Site visits

Stakeholder mapping

Stakeholder mapping

Starfish

Starfish

Super Hero

Super Hero

Tech review

Tech review

User stories

User stories

Validate a concept

Validate a concept

We do and we value

We do and we value

Weather

Weather

Well, learned, different and puzzles us

Well, learned, different and puzzles us

Wells and worries

Wells and worries

What happened?

What happened?

Wow, wondering or worried

Wow, wondering or worried

Your superpower

Your superpower

What roles make up the Delivery Team and what do they do throughout delivery?

Agile coach/mentor

Agile coach/mentor

Backlog grooming

Backlog grooming

Budget / resource management

Budget / resource management

Building the product

Building the product

Daily stand up

Daily stand up

Decision making

Decision making

Embody 5 scrum values

Embody 5 scrum values

Environment building

Environment building

Mapping involvement

Mapping involvement

Mock ups and wireframes

Mock ups and wireframes

Monitoring progress / keeping the team accountable

Monitoring progress / keeping the team accountable

MVP (minimum viable product)

MVP (minimum viable product)

Protect the sprint backlog

Protect the sprint backlog

Research

Research

Risk management

Risk management

What do you want to do now?

Delivery sign-off

At the end of the last sprint, we go through the feature list and make sure that all requirements have been completed to the agreed acceptance criteria.

If the product owner gives consent to go live, the scrum master will set a date and begin the go-live task list.

When the service has gone live, it’s important to hand over the backlog to the product owner – they will add any new requests to the list and come back when there is enough to warrant the next iteration.

Completed backlog

All tasks have been completed to an acceptable standard and signed off by the product owner.

Minimum viable product (MVP)

The product exists and meets the minimum requirements of the customer.

Testing

The product has been tested by real users, automated checks and peers in a tech review.