The Transformation Team

 Introduction to Agile

What is Agile?

Agile is a way to manage projects. It is an umbrella term for a set of globally accepted methodologies. Using it will deliver value quickly.

It’s based on the values and principles expressed in the Agile Manifesto, 2001. Agile can help you handle complex situations or challenges by turning them into simple options and solutions.

It breaks down larger projects into smaller, manageable chunks, each of which delivers something of value, which can be put into the world to gain feedback from users or stakeholders.

 

Agile Principles

Agile is a set of beliefs dedicated to finding the right balance for success.

Here are the 12 principles based on the original Agile Manifesto 2001.

Agile Priorities

The Agile Manifesto states it has found better ways of working.

While there’s value in the items on the right, the focus should be on those on the left.

 

The Benefits of Agile

Here’s how Agile can help your challenges, big or small.

Visibility - When projects lack visibility and clarity, Agile provides transparency. Digital tools can help, along with physical boards displayed in shared workspaces. Any team or project can then share and collaborate.

Value-based prioritisation - Agile helps us to spend time on what really matters, not on areas of little value. In this way we can deliver value earlier. How do we know what’s of value? Data or evidence tells us. Prioritisation happens at all levels and project stages.

Adaptability - When goalposts shift, Agile has adaptability built-in. It’s designed in a way that you can easily refocus and re-plan as necessary - rather than follow a fixed plan.

Risk management - With Agile risks are actively managed and don’t sit on a spreadsheet with a progress status.

 

Working in an Agile team

Agile puts people and interactions over processes and tools. People in Agile teams work with a sense of urgency that is tough to match. That’s because responding to change is their core value. They know how quickly today’s environment can change. So, they use adaptive planning to make sure they deliver the highest value items first.

Roles are adopted in the Agile team and its framework, which helps form a cohesive whole. And knowing how these roles contribute is important.

An Agile team aims to be:

• Highly adaptable and flexible
• Responsive to rapid change
• Highly productive and efficient
• Positive and forward thinking
• Motivated and collaborative
• Dynamic and self-organising
• Durable and strong 

 Agile Roles

In Agile, the focus is on the people. The first principle of the Agile Manifesto positions Individuals and Interactions over Processes and Tools.

People in agile teams work with a sense of urgency that is tough to match. That’s because responding to change is their core value. They know how quickly today’s environment can change, so, they use adaptive planning to make sure they deliver continuous value.

“Roles” (not jobs) are adopted in the Agile team and its framework, which helps form a cohesive whole. And knowing how these roles contribute is important.

The Agile Team

An Agile team is a cross-functional group of people that have all the capabilities that are necessary to deliver the product or service required. Ideally, the team is small (3-9 members), lean and results-driven.

Agile specifies three major roles that play a part in the team: Product Owner, Scrum Master, and Team Member – sometimes called Development Team Member. You may also require Subject Matter Experts that may have a particular skill that you require for just a sprint or two. Besides these roles and depending on the type of Agile methodology you adopt there may also be a Product Manager or Business Owner.

The Agile roles describe the key responsibilities for those in the team. They aren’t job titles. Anyone can perform one of the roles, irrespective of their job title. Whatever the role adopted in the Agile Team, there are a number of common features and expectations.  Those fulfilling the Agile Team roles:

• are fully dedicated to the team, and are fully committed to the work
• are motivated by a shared vision and commitment to deliver value to the user
• improve collaboration by using regular feedback loops
• are facilitated to allow daily communication and attend regular Agile events
• understand that the tangible delivery of value encourages trust and reduces uncertainty and risk
• continuously and actively engage with other teams to manage dependencies and resolve impediments
• develop relationships within the team based on trust, facilitated by a common mission and objective

meet their responsibilities through constant communication and collaboration, and through fast, effective, and empowered decision-making

 

The Agile Team member make up the majority of the team.  Each Team Member brings their own unique set of skills to the team, and will develop more skills as they interact with other team members. The skills required will depend on the product or service being delivered. For example, a digital project may require more technology expertise than a policy project.

Agile Team members are the “creators and deliverers”.  They get stuff done. 

Agile Team members commit to a number of working practices. They:

• self-organise - manage their work within the context of the team and project
• ensure the optimum value across the full lifecycle of the project
• estimate the size and complexity of the work
• determine the technical design in their area of concern within any appropriate polices or guidelines
• commit to the work they can accomplish in a sprint
• test the output of their work to ensure quality
• deploy the output of their work into a live environment
• contribute to backlog refinement and creation of stories
• find ways to continuously experiment and improve on their work

 

The Product Owner sits within the Agile Team, and is the voice of the business, the user and the Team’s stakeholders. They are empowered to make timely decisions about the requirements of the product or service they are developing and must ensure maximum value.  The Product Owner is responsible for the content of the Team Backlog, and the Features/User Stories within it.  They must also set the sprint priorities and are responsible for defining the Acceptance Criteria of the work within the team.

The Product Owner is the “value maximiser” of the team.

The Product Owner commits to a number of working practices.  They:

• ensure effective planning, are the main source for story details and priorities and will accept the plan the Team Members create
• are responsible for backlog refinement – building, pruning and maintaining the team backlog
• support acceptance criteria development, and are the only team member who can accept stories as done, fulfilling a quality assurance function
• understand enabler work, engaging with design standards or policy functions to facilitate quality and continuous value
• attend team demos and retrospectives
• are highly invested in the team and its success
• are very active in requesting input from stakeholders and subject matter experts to progress the backlog

 

The Scrum Master sits within the team as their ‘servant leader’.  They are often from the business or from a programme management function, but any Team Member can adopt the Scrum Master role with the correct training.  The Scrum Master acts as the Agile Team’s facilitator and coach.  They support the team to develop their Agile mindset and maturity.

The Scrum Master co-ordinates inter-team cooperation and ensures an effective team dynamic.

The Scrum Master is the “practice maximiser” of the Agile Team.

The Scrum Master commits to a number of working practices. They:

• support the team to ensure they meet their goals
• promote and implement Agile methodologies and coach teams to understand the Agile principles
• ensure robustness of approach – for example user-driven, iterative planning
• support team capacity estimations and velocity
• manage the Kanban board, ensuring teams are appropriately tracking and managing their work and risks
• support the team to achieve in areas such as quality, predictability, velocity and transparent communications
• facilitate team events such as daily stand-ups, demos, retrospectives and sprint planning
• prepare for wider stakeholder events, including Show and Tells
• work with the Product Manager to remove impediments/blockers
• ensure alignment with the rest of the Agile community

 

The following roles are not always present in an Agile Team, but it is helpful to understand them.

The Subject Matter Expert or domain expert is a person who is an authority in a particular area or topic, or a particular talent required by the Team. When you bring this specialist knowledge to the Agile Team, they can make more informed decisions and create a better plan to achieve their sprint goals.

The Agile Team may need the SMEs for different purposes and at different times, but they are expected to answer questions and perform tasks to improve the output of the team. During planning, the Team will identify when information or actions are expected from the Subject Matter Expert, so they can know when and where their capability will be required.

 

The Product Manager does not sit within the Agile Team, but sits at a programme level, and is ideally from the business.  The Product Manager develops the vision and roadmap for the work and works actively with stakeholders to understand what enabling work will be required. The Product Manager is responsible for building an effective Agile Team.

The Business Owner is often thought of as the main (or lead) Stakeholder for the Team. Business Owners are responsible for business performance, technical delivery, compliance and return on investment.

Both roles:

• are an authority on the overall market and competitive dynamics
• are the voice of the customer in all situations
• responsible for owning and articulating the strategy, vision and roadmap, ensuring delivery of the Epics
• ensure value through business case development
• are responsible for securing funding for development
• are required to attend Show and Tells and have a key role in planning
• are responsible for upper management liaison
• deal with other business service areas such as marketing, resource management and HR

 Agile Events

Agile Events are the meetings that give Agile practice (and variants like Scrum) its regularity and structure. They ensure that everyone is in sync.

They encompass all of the meetings required to maintain the cyclical process that allows teams to inspect and adapt their work.  Each event has its own specific purpose, cadence, and time-box, which allows teams to maximise the productivity of each meeting.

See the Gov.uk’s guide to running Agile events.

Sprint Planning

What is sprint planning?

Sprint planning is where the team determines the backlog items they will work on during that sprint and discusses their initial plan for delivering them.

Sprint planning should be held at the beginning of each sprint. In this session, teams should plan all of their work to be completed in the next increment, however long that is.

During planning, tasks should be discussed, broken down, prioritised and assigned.

Why should I run a sprint planning session?

Sprint planning helps assess the work to be done, and which goals and objectives to be aiming for in the time period, setting the team up for success.

Who is responsible for running sprint planning?

In theory, sprint planning is usually initiated by the team’s Scrum Master, but the team should aim to rotate this responsibility as often as possible.

The whole team must be present, as should the Product Owner where possible.

How often should I run them?

Planning should be run once per sprint, for example, once a week if your sprints are a week long, or once a fortnight if you are running fortnightly sprints.

I’ve run my first sprint planning, now what?

After sprint planning, you should have:

• a prioritised sprint backlog
• a sprint goal, or clear objectives to be achieved by the end of the sprint
• Stories and tasks that are broken down into tasks, that are of a manageable size

You might want to articulate your tasks as user stories . If you are uncomfortable with user stories and you are struggling, try rewriting your to do’s with an actionable verb at the beginning.

For example:

• Write first draft marketing plan
• Schedule meeting with Communications
• Calculate numbers for monthly report

This helps the rest of the team, and anyone else who might see your backlog to immediately understand the task in hand a bit better.

 

Retrospectives

What is a retrospective?

A retrospective is time set aside to reflect on the work that has been done.

Why should I run one?

As well as allowing you to reflect on the work that has been done over the last period, it also helps everyone air anything that has frustrated them and over time, it encourages the right kind of transparency needed for the team to grow.

Celebrate success, explore failures and discuss improvements to be made next time. It helps the team arrive at amicable solutions and carefully considered tests. 

Who is responsible for running them?

In theory, a retrospective is usually initiated by the team’s Scrum Master, but the team should aim to rotate this responsibility as often as possible.

The whole team must be present, as should the Product Owner where possible.

How often should I run them?

At least once a sprint is recommended, but if you are running 2 week sprints and you feel running a retro once a week is beneficial, adapt your working practices to suit this.

I’ve run my first retrospective, now what?

Change the format from time to time to keep it light, useful and suited to the number and skill sets of your participants. If you are looking for ideas, there are plenty of great online resources to spark your imagination:

• Fun Retrospectives
• Retromat

If you need help getting set up with regular retrospectives, or you need a hand running one, get in touch. 

 

Show and Tell

Show and Tells provide the opportunity to demonstrate work so far and receive feedback.

This team review is a regular meeting which gives team members the opportunity to demonstrate their work and receive live feedback from other Programme team members. Stakeholders like sponsors or users can also be invited to this meeting.

Teams can show the most important work they’ve delivered so far, talk about what’s been learned, explain their plans for the next few weeks and answer questions. It also gives all teams the chance to see how their work relates to each other’s efforts.

 

Workshops

Workshops are meetings working to a brief to deliver a set of tasks which will add value.

Workshops have a clear objective and the right set of people who are chosen and empowered to agree a plan. They are good for solving a problem, building a plan, co-creating solutions or making decisions.

There are many benefits:

• Rapid, high-quality decision-making
• Greater buy-in from all stakeholders
• Builds team spirit
• Builds consensus
• Clarifies issues

It’s the responsibility of the Facilitator to set the process to assist the group in achieving its objective. Some high-level principles are:

• Start on time – as timescales are constrained
• Respect the views of others – all opinions are valid
• Silence may be seen as agreement – if participants don’t speak up then they’ll be assumed to have agreed the point under discussion
• Each individual in the group has a responsibility to maintain focus.

Workshops may incorporate guidance frameworks or ‘canvases’ to help productivity and the quality of the outputs. If you'd like to know more about the sort of items that may be of use get in touch. 

 Creating and Managing a Backlog

Using a Backlog

What is a backlog?

A Backlog describes a holding area for upcoming work activities, which are intended to address user needs and deliver business benefits. Owned by the Product Manager, it also contains enabler work necessary to help the team deliver the work required.

In the simplest of terms, a Backlog is a list of all things that needs to be done within a project. It replaces the traditional requirements specification common in many projects. The items within a backlog can have a technical nature or can be user-centric e.g. in the form of user stories.

Each backlog item should:

• Have the appropriate level of detail to understand the work
• Have an estimation of the amount of estimated time or effort the item will take to deliver
• Be prioritised – with the more valuable work at the top of the backlog
• Account for emergent work as the team progresses with their work

Managing a Backlog

A well-managed backlog creates a living ‘roadmap’ for your work. It makes planning easier and creates transparency with stakeholders – creating clarity on work that they may not have considered but must be done.

It is the team’s responsibility to make sure the backlog is updated to mark the progress of tasks and activity regularly, preferably on a daily basis. Backlog management or ‘refinement’ should also be done on a regular basis, preferably during every sprint. This should include:

• Reviewing and updating backlog item descriptions and developing acceptance criteria
• Working within the teams and with other teams to establish technical feasibility and scope
• Finding ways to split backlog items, if necessary, into smaller chunks of work that are easier to complete
• Identifying the enablers required to support or do the work and capabilities that may be necessary, for example data or IT capability
• Establishing the required capacity to complete the backlog item

Backlog prioritisation

Prioritising backlogs is a critical part of ensuring that we deliver the right things. Every team faces the problem of how to balance the backlog of internally-facing work with that which delivers immediate business value.

When prioritising teams should be considering:

• Value
• Risk
• Dependencies
• Constraints
• Cost / Effort
• Regulations
• Capacity

It is often helpful to map the backlog items using these criteria to establish their relative importance. The scale below is an excellent barometer to use when prioritising a backlog.

               

Driving value using Agile

Agile breaks down projects (large or small) into manageable chunks, delivered in sprints or iterations. At the end of each sprint something of value is produced. The product produced during each sprint should be able to be put into the world to gain feedback from users or stakeholders.

Agile has designers, developers and business people working together simultaneously to deliver value. Testing is integrated throughout the process. This means higher overall quality and less time spent on quality assurance at the end of the process.

Drivers for delivering value:

1. Faster - the solution needs to be delivered quickly

2. Better - quality is key, the solution has to meet to quality standards

3. Cheaper - budgets are a priority, the solution needs to be more cost-effective

To ensure we are working on the right things and creating value, our approach to breaking down large projects is to develop Epics, Features and Stories.

 Epics Features and Stories

Epics

What is an Epic?

An Agile Epic is a large body of work that will be delivered over multiple sprints. Often supported by a business case, they are significant pieces of work that strategically add value. Epics help organisations break their work down, organise that work, while continuing to work towards a bigger goal.

In a sense, epics in agile are similar to epics in film or literature. Epics can be broken down into specific pieces of work, called Features. These are based on the needs and requests of customers or end users and is sized or split as necessary to be delivered by the Agile teams.

Epics are a helpful way to organise your work and to create a hierarchy. The idea is to break work down into deliverable pieces, so that large projects can actually get done and you can continue to deliver value on a regular basis.

For example, the design, creation, testing and delivery of a transactional website or app, or complex training programme is about the right size for an Epic.

Writing an Epic

A well-written epic is a key to have a good understanding and material to refer in case of any doubts during the development work. It helps in avoiding a lot of conflicts and misunderstanding in the team and with stakeholders. Since this is what you will refer to when breaking down the work it's extremely important to collaborate when developing your Epic.

As a simple guide, the main elements of an Epic include the user, the product and design requirement, expressed as a story that encapsulates the future state. A simple way of structuring an Epic is as follows:

Features

What is a Feature?

A feature is a chunk of work from the Epic – a deliverable that adds value and moves towards completing the Epic.

A feature should:

• provide business value
• it should be estimable – it must have enough definition for the team to provide an estimate of the work involved in implementing it
• be small enough to fit within 1 to 3 sprints – therefore, if it is too big, it should be broken down further
• be testable – you should understand what test a feature should pass in order to be acceptable to the customer.

Writing a Feature

As a minimum, the expression of a feature should contain a short descriptor of the item of value, a description of the benefit of the feature, and the acceptance criteria (the points of quality or completion the feature must achieve, UAC for short).

 

Stories

What is a Story

Stories, also called “user stories,” are short requirements or requests written from the perspective of an end user.  They may also be enabler tasks that support the work of completing a feature. Stories are things that teams can usually complete within a single sprint.

Writing a Story

A Story should describe a need that can be satisfied by introducing a new feature or changing an existing feature. In other words, stories identify what someone wants to accomplish with your product and why.

Now that we know about Epics, Features and Stories let's look in more depth at Stories to see what else can be done to more effectively manage workload.

 

Story Splitting

What is story splitting?

Story splitting is the practice of breaking big pieces of work down into smaller, deliverable pieces of work.

Why do I need to split my stories?

Splitting stories helps teams to understand the tasks and complexities involved in delivering a piece of work.

You may want to split your stories based on: 

• Steps in a workflow
• Business objectives
• Overcoming user problems
• Data
• Anticipated user behaviour
• The ‘stuff we know’ from the ‘stuff that needs more research’
• Operations and interactions
• Effort
• Complexity

All of this is explained in much more depth, with examples, on the Agile For All website.

How do I split my stories? 

Think about all of the different tasks you need to do to complete a story and break these out into stories in their own right.

There are many patterns to help you do this, and many ways to ensure your stories retain their quality as you break them down. Use the INVEST principles to guide you.
For example:

Big story

• As a Head of Admin, I want to publish a piece of content to the UofG website about my department.

Small, split stories

• As a Head of Admin, I want to draft a piece of content about my department
• As a Head of Admin, I want my content to be engaging and visual
• As a Head of Admin, I want my peers to review my content

 

Story Mapping

What is story mapping?

Story mapping is a method for arranging user stories to create a more holistic view of how they fit into the overall user experience.

What are the benefits of story mapping?

Story maps:

• help develop shared understanding within and across teams
• make estimating more realistic because everyone has a better understanding of all of the tasks it takes to complete a piece of work
• help visualise dependencies
• help visualise and capture ideas as well as tasks
• make it easier to prioritise tasks and outcomes

 

Visualising stories

When working with your team to build story maps, try creating simple, visual prompts to help support your discussions. You could do this on post-it notes or small cards. The trick with this is to write down everything!

One thing that goes wrong a lot when you are having discussions about work to be completed, is ideas get lost, so write these down alongside your work. You can always get rid of them later if they are no longer relevant.

Step by step guide

Users

Start with your personas or user insights. Place these at the top of your map.

Activities

Activities are the common goals and the steps that belong to the user journey. You will find these in the ‘needs’ part of your personas.

Tasks/User Needs

Tasks or User Needs provide a bit more narrative on the tasks on the activities above. These should flow left to right and indicate user journeys or behaviour.

Outcomes

Outcomes are the stories that start to explain chunks of work that need to be completed. These can be articulated as features, epics, or jobs to be done, whatever works best for the team. Map these down the way, from the task/user need they are associated with.

Timescales

Don’t get too hung up on timescales, but use your map to begin a conversation about ‘when’.
This should get the team talking about priorities. If it is too soon to make a decision, use the ‘now, soon, later’ format.

Build on it

Add your other personas to get a full view of all your priorities.

Tasks

You should now be able to get a clearer view of what stories and tasks you might want to take into your team’s backlog.

Add anything else that helps tell the story

Around your map should be product or service goals to keep people focused, sketches, storyboards, wireframes, sticky notes with feedback from users and stakeholders - anything of relevance.

 

 

 

 

 

 

 

 

 

 

 

There is no right or wrong way to story map

Remember ultimately that stories are just a means of shared understanding, and there is no concrete way to write them correctly or incorrectly. The most valuable part of story mapping as a team is to develop shared understanding.

 

How can we help?

Firstly, it's a lot of information to take in, so having a copy of the content that you can review and refer to offline might help - Epics Features and Stories Pack

If you need some advice on get started with story mapping, however, the Responsive Solutions team are happy to assist.

Get in touch with us to explore the ways we can help.

 Agile Glossary of Terms

A

Agile – Umbrella term for a set of methods and practices based on the values and principles expressed in the Agile Manifesto. Agile emphasises the ability to create and respond to change in order to succeed in an uncertain and turbulent environment.

Agility - The ability to create and respond to change in order to succeed in an uncertain and turbulent environment.

‘Agile’ working – a term sometimes used in UofG to describe adopting a flexible approach to work e.g. hot desking, working from home etc. The term 'flexible working' should be used in its place to avoid confusion and misunderstanding.

Agile Manifesto – The Agile Manifesto, also called the Manifesto for Agile Software Development, is a formal proclamation of four key values and 12 principles to guide an iterative and people-centric approach.

Agile Teams – The Agile Team is a small cross-functional group who have the ability and authority to define, build and test the agreed deliverables – all in a short time span (typically called an iteration or a Sprint). The team includes all individuals necessary to successfully deliver the agreed outputs, supported by specialists where applicable.

B

Backlog – a backlog may be referred to as either of the following:

- Programme Backlog – The Programme Backlog is the highest level backlog. It is a holding mechanism for the upcoming business and enabler Epics.

- Team Backlog – This backlog is a prioritised list of User Stories and Enabler Tasks needed to deliver the features. This backlog is prioritised and managed by the Product Owner.

- Sprint Backlog – Is a set of Team Backlog items which have been selected for action in a specified Sprint (a sprint is typically a two-week period).

Backlog item – A single entry or item on a Backlog. Usually in the form of an Epic, Feature, User Story or Enabler task.

Blockers/Barriers – Anything that prevents a team from completing actions, tasks and goals.

C

Customer – Customer or end-user is whoever uses the end product or service. Within UofG customers may be staff, students or external members of the public.

D

Daily Stand-Up Meeting is a time boxed daily meeting of 15 minutes where the Agile Team discusses how they are progressing towards the Sprint goal. During this meeting, each team member describes what they did yesterday, what they are going to work on today, and any blocks they are encountering in delivering iteration goals. The daily scrum meeting is a time effective meeting – short, sharp and to the point.

Delivery Team (also known as the Agile Team) – the group accountable for managing, organising and doing all the development work required to create and deliver against the agreed Sprint objectives. The Team excludes the Product Owner and Scrum Master.

E

Enabler – Essential component or task that supports the activities needed to provide future business functionality. They occur at all levels and are captured in various backlogs as enabler Epics, enabler Features and enabler Stories depending on their level.

Epic – An Epic is a large piece of work, usually requiring financial approval prior to development. Epics are usually broad in scope, short on details, and will generally take many Sprints to implement. They commonly need to be broken down into Features, Stories/Tasks so the Team can work on them.

F

Feature – A feature is a chunk of work from the Epic – a deliverable that adds value and moves towards completing the Epic. It is a distinguishable solution component, delivers value and fulfils stakeholder needs. An Epic will be broken down into chunks called Features which in turn will be broken down into Stories. Features include a statement of benefits and defined acceptance criteria.

K

Kanban – Literally a visual mechanism to control work progression. It is a way of visualising and improving workflows and processes. Typically, it is done using a visual board which in its simplest form tracks work through three columns: ‘To Do’; ‘In Progress’ and ‘Done’.

L

Lean – Lean methods are often used in conjunction with Agile methodologies. Lean is designed to help teams focus on reducing waste, delivering quickly, learning and improving and using evidence and data to make decisions.

M

Minimum Viable Product (MVP) – A version of a new product or service which allows the team to deliver value, collect the maximum amount of learning about customers with the least effort. The final, complete set of features is only designed and developed after considering feedback from the product's initial users.

P

Programme Planning – Is a face-to-face planning event which aligns all the Agile Teams to a common goal, allows for dependencies and risks to be surfaced and delivers understanding of each of the teams’ focus for the next delivery iteration.

Product Backlog – A Product Backlog is an ordered list of items representing everything that may be needed (create, maintain and sustain) to deliver a specific outcome related to that product. The Product Backlog is managed by the Product Owner.

Product Owner – The Product Owner is responsible for ensuring the Agile Team is working on the highest value items and maximising the value of the product. The Product Owner is the sole person who manages and prioritises the Team Backlog.

R

Roadmap - A roadmap is a plan that shows how a product or service is likely to develop over time. It maps the main items, features that are required to achieve an objective, typically on time scale anything from 6 months to 3 years.

S

SAFe – SAFe (Scaled Agile Framework) is an Agile development framework. It is one of a number of frameworks that addresses how to manage multiple teams working in Agile.

Scrum – Scrum is a process framework used to manage product development and other knowledge work. Scrum is the most commonly used Agile method and is based on an incremental approach to the delivery of products and services.

Scrum Master – The Scrum Master is a role within the Agile Team. The Scrum Master is a servant leader who is responsible for ensuring the Agile Team lives Agile values and principles and follows the practices that the team agreed they would use.

Self Organise – The management principle that teams autonomously organise their workloads themselves. Self organisation happens within boundaries and against given goals. The team choose how best to accomplish their work rather than being directed by others outside the team.

Sprint – A time-box event of 30 days or less, in which a team commits to a goal and completes certain work output. Sprints are done consecutively, without intermediate gaps.

Sprint Planning – Time-boxed event at the start of the Sprint. The Agile Team determines and discusses the most high value items on the Team Backlog, creates a plan for the next Sprint and takes the items off the Team backlog and onto the Sprint backlog.

Story – Also called User Story is the description of something that a User actually wants from a Feature containing just enough information for the Agile Team to produce a reasonable estimate of the effort required to then create, test and implement. It ordinarily reads: ‘As a ........ I want…..so that I can.........’ and describes the intended outcome by the desired behaviour. Features are broken down into Stories by the Delivery Team and a story should fit into one Sprint.

Subject Matter Expert (SME) – The Delivery Team can bring in subject matter experts to support specific requirements for delivery. The SME will work alongside the Delivery Team and the Delivery Team can agree with the SME how they will work together.

T

Task – The tasks are the actions that can be part of the Team Backlog which the Agile Team need to complete.

U

User Acceptance Criteria – criteria agreed to determine if a User Story is complete.

W

Waterfall Project Methodology – This is a design process used in development processes in which progress is seen as flowing steadily downwards like a waterfall. It includes phases of conception, initiation, analysis, design, construction, testing, implementation and maintenance.