Approach to projects

There are a number of ways to deliver a project, including Agile or Waterfall. The Digital team uses Agile methodology for our digital project work. Agile means that we are able to break down projects into smaller chunks and prioritise the things that need doing first so we can publish sections of the website more quickly. It helps us meet tight deadlines, complex requirements and the unpredictability of building a website from a development and a content creation perspective.

Digital principles

As part of Agile, we've created and work within a set of digital principles. These set and establish digital best practice and provide a framework of how we will work with you to deliver products that are suitable for target user groups.

The sprint process

When you work with us as a subject expert and stakeholder, you are considered a member of our team. We will work with you on a project in a two-week cycle called a 'sprint' and, wherever possible, you will be invited to join us and work with us in the office.

This two-week period of time is allocated to a particular phase of a project. By the end of the sprint, we hope to have delivered the key content that is identified and prioritised as a 'top task' for the target audience.

Sprint discovery

Three weeks before the start of a sprint

Before we start working with you we carry out a period of 'discovery'. This is so that we can find out whether users need the proposed content. We do not create content or build services during this phase.

We use this phase to:

• identify business requirements
• complete an audit of existing content
• identify duplicate pages or services
• do a complete analysis of the analytics on the existing content
• complete a benchmarking exercise where appropriate
• identify how we will measure success in the future
• make recommendations for the best solution for users based on best digital content practice and our findings
• share a report of those findings with you as a subject expert or stakeholder
• talk you or any other stakeholders through the findings and recommendations

By carrying out this period of discovery we are able to better understand the requirements and goals of the project which helps us manage our sprints and work with you more effectively.

User story planning

Two weeks before the start of a sprint

We create user-centred, or user-focused content, for all our digital channels. This means that we always think about who the content is for by putting ourselves in the users' shoes. Whenever we produce a new piece of content, we create a user story. It's a common way of describing a user need and helps us focus our writing on what the user wants to achieve.

You can see how a user story is formatted in our guide to creating user stories for web content.

To gather user stories we'll meet with you and other subject experts from across the University and hold a user story planning workshop.

As a subject matter expert, you know your target audience and subject domain so we think it's important to involve you at the beginning of a project and through the process.

During this phase we:

• identify subject experts
• meet subject experts
• identify and agree on target users with subject experts
• write user stories with subject experts
• prioritise 'top task' with subject experts based on the user stories generated
• ask subject experts to nominate the most appropriate person or people to join the sprint team
• invite the nominated people to sprint planning

User research

We also like to do user research on high-risk hypotheses before we push a section of the website live. As part of the sprint team you'll join us in meeting with real users to see where they may have problems or experience confusion in performing typical tasks related to the content. This helps us check how easy the content is to follow and we can identify where there may be improvements to make.

User feedback

After we complete a sprint, and content goes live on the website, Digital continuously gathers user feedback and data and use it to inform developments on the website. Continuously improving the website is an incremental process and we work iteratively. We often schedule user feedback into further sprints to improve content or pass it on to you so that you can integrate it into your own content maintenance and improvement processes.

Sprint planning

One week before the start of a sprint

One week before the sprint starts you will join us in a 'sprint planning' session. This is a planning meeting where we set up a backlog of work together and agree on a goal (the objective of what we'll achieve together during the two weeks).

Before the planning meeting

In preparation for the planning meeting the Digital team will:

• create task board of user stories using the stories gathered in our user story planning session
• add prioritised stories to a backlog and organise, based on the top tasks we've identified
• map existing content to user stories by looking at our website and seeing if content already exists to address the user need
• invite nominated stakeholders to the planning meeting

During the planning meeting

As part of the sprint team you will help us:

• make sure that the target users are correct
• make sure user stories have been captured correctly
• talk through the backlog of stories so that we all understand what is required
• identify any other supporting tasks needed to deliver the project
• estimate story complexity so that we can work out how much the team can deliver during the time period
• agree on and set a goal

Sprint

The sprint is the time-boxed period that we allocate to content delivery. It starts on a Tuesday and ends ten working days later on a Monday. We work on product delivery for eight working days during that allocated period. Fridays are dedicated to content maintenance and business-as-usual for the University website.

We'll ask you to block out your diary so that you can focus on the project with us. This period is the time when we create and produce content based on the agreed sprint goal and the tasks we created during sprint planning, so you'll need to make sure you're available to work with us on the delivery of your project.

Sprint stand-ups

Every morning you'll join us in a 'stand-up' - a short daily catch up where we all, as members of the sprint team, talk about the following questions:

• "What did you accomplish since the last meeting?" (the single most important thing you worked on towards achieving delivery)
• "What are you working on until the next meeting?" (the single most important thing you will be working on towards achieving delivery)
  
• "What is getting in your way or keeping you from doing your job?" (are there any impediments, obstacles, or risks to you being able to accomplish what you need to do for delivery of your task or the sprint)

By talking about these things daily, we can keep up-to-date on what everybody is doing, make sure that we still on track to meet our sprint goal and also if there are any problems to delivery that are raised, we can work out the best ways to resolve them together.

Overview

During the sprint we will do the following:

• stand-up to review stories in progress, identify blockers and talk through upcoming stories
• reiterate goal and talk through upcoming stories
• assigns user stories and tasks to members of the team
• start sprinting on the agreed stories
• add any new stories to backlog or icebox to prioritise and estimate
• show previews of the product to the product manager and any major stakeholders and talk through it in context
• get sign off
• ship the product (make signed-off content go live on the website)
• invite you and any other people that have been working on sprint to a retrospective meeting

Retrospective

One week after sprint

We're always looking to improve on how we do things, so we hold a meeting at the end of the sprint called a retrospective (also known as a retro) which allows us to reflect together on what went well, what could have gone better and what we can learn to do better for future sprints.

It's important to remember that we have an open culture in the retrospectives. Every member of the team is invited to speak and the meeting is a safe environment to talk openly. Each meeting starts with a reminder of the 'Prime Directive' as defined by Norman L Kerth in his book Project Retrospectives. This helps us make a retrospective positive and effective meeting.

Prime Directive

Regardless of what we discover, we must understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.

In the retro we:

• remind everybody of the Agile 'Prime Directive'
• review the sprint goal and confirm if it was met
• discuss what went well during the sprint
• discuss what didn’t go so well while making suggestions for how to improve things next time
• prioritise the things we may need to change for next time

After the retro we:

• share write-up and priorities with the whole team