Writing Agile User Stories - A Practical Guide

This section provides you with a valuable introduction to Agile, Scrum and introduces you to a working example that we use throughout the course.

For many viewing this course, the information will be familiar but may act as a refresher.  That said, I'd take a moment to view the lecture introducing the working example that will be referred to throughout the course. 

For those who don't understand the concepts behind Agile and Scrum, this section will be essential to understand the concepts discussed during the rest of the course.

Business Driven Development is a term applied to a methodology in which products and services development is developed based on requirement provided from the perspective of the business rather and technical terms.

I also introduce User Stories at a very high level explaining the reasons for User Stories and why they are constructed the way they are.

This lecture provides context for User Stories within a BDD framework.

Agile development is a widely adopted and accepted way for modern and effective businesses to develop products and services.  This lecture introduces the key principles that underpin it.

Scrum is a framework that applies Agile principles to a development methodology.   This lecture provides a high-level introduction to the key components of Scrum: roles, artefacts and events.

At first, Scrum can be a little confusing.  This lecture walks you chronologically through the Scrum lifecycle.

In order to help understand how to apply User Stories to your project, we introduce a working example in this lecture that is used for examples throughout the rest of this course.

In this lecture, we go over the material covered in this section on writing great User Stories.

Personas are a fictional user of your product or service.  In this lecture, we cover how and why we use personas when creating User Stories.

A User Story has a very particular structure.  In this lecture, we also examine its structure and provide examples of how to create and present User Stories.

A User Story has a lifespan, from inception through to completion.  In this lecture, we outline the structure and process of the Three Cs as a way of describing and tracking the lifecycle of a User Story.

Understanding the broader context that a User Story sits within is important to communicate its meaning and value to the stakeholders and Development Team.  In part of this lecture, we describe a typical structure and breakdown that leads from an overriding coarse-grained business objective to the more granular User Story being created.

If, after estimating the size of a User Story, it becomes clear that the volume of work required to implement it won't fit into a single Sprint.  In this lecture, we also discuss the various approaches to splitting a User Stories making sure that we continue to add value after each iteration.

Words often don't cut it when discussing the details around a requirement or User Story.  This lecture discusses why we should consider prototyping prior to developing a User Story and the approaches we might take.

Once we've created our User Story we need to understand the effort required to complete the work and then, once completed, ensure that we've developed the User Story as expected. 

There are a number of techniques we can use to estimate the size of a User Story.  In this section, we discuss Story Points as a way of assigning a size estimate to a User Story.  We then go on to discuss Planning Poker, a game that the team can play to help achieve more accurate estimates and understanding of User Stories.

In the same way that we have a specific structure for a User Story, we have a specific way to write Acceptance Criteria.  In this lecture, we will break it down and discuss a couple of examples.

Additionally, QA can often provide a different perspective on User Stories and uncover angles that haven't been thought of previously. The second part of this lecture looks at the appropriate time to include QA during the development of a User Story and their approach to helping write Acceptance Criteria.

We close the course with a summary of the key points covered.