Stakeholders Defining High Level Epic’s
An Agile Epic is a high level outcome which has the following attributes:
Short definition – e.g. As a Trading System, I am able to connect to Market Data XYZ via an API
Detail – e.g. defining the headline requirements and outcomes of the API connection. It is important to note that this is not a Business Requirement Document, although the Epic can refer to such a document should it exist. There’s a lot to be said about Business Requirement Documents which are in a separate post.
Acceptance Criteria – e.g. a list of criteria which must be met to define the Epic as done. For example this may include functionality for the API as well as any non-functional criteria.
Size – more on sizing later, but an Epic should have an approximate sizing which should relate to but be abstracted from numbers of days. More on detailed sizing later, but for now consider a t-shirt size approach, where an Epic can be anywhere between XS and XXL.
Team Assignment – typically an Epic will be assigned to one team. If an Epic is XXL for example and can be split across teams, one team should still own the Epic as a whole.
Deadline – if one exists – e.g. driven by external factors or project dependencies.
Product Owners Defining User Stories
An Epic typically has a number of User Stories. Once an Epics’ User Stories have been completed and accepted, the Epic is done. A User Story has the following attributes:
Headline – e.g. As Team X we have delivered technical requirements to 3rd Pty ABC.
Description – e.g. including materials* such as spreadsheets and powerpoint etc either for internal or external use.
*=highly recommended in all cases to keep documents in Confluence and not on individual users drives or in emails. Strive to keep all docs public (or at least in a hierarchy) and use links in emails and User Stories etc.
Acceptance Criteria – similar to an Epic, a User Story should have a set of Acceptance Criteria which defines successful delivery of the User Story. There’s a lot to say about Acceptance Criteria – see this post for more detail.
Size – similar to an Epic, a User Story has a size. The size of a User Story typically relates to the estimated number of days to complete, but it can also be abstracted (more on this in a separate post). Size must be estimated using Fibonacci numbers (but cunningly starting at 0.5 to allow for small User Stories) – i.e. 0.5, 1, 2, 3, 5, 8 and 13. These numbers intentionally disallow estimating a User Story as being 4 days instead of 3 days.
Owner – Each User Story should have one team member assigned as an owner even if in reality several people are contributing to delivering the User Story. Ownership can change if needed even during the lifetime of a Sprint.
Defining the Agile Backlog, Prioritisation and then Refining
There are typically two backlogs – one is a list of Epics and the other is a list of User Stories.
The Epic Backlog is a list of all high level outcomes required for delivery by the Stakeholders. The priority of these Epics can change each Sprint.
The other backlog is the individual User Story Backlog. An Epic may have 100 User Stories, but in this current Sprint we may only have prioritised ten.
The Refinement process (which typically happens after the prioritisation) reviews the prioritised User Stories, adding more information and sizes with the Agile Team to form the scope of work for the next Sprint.
When refining and building a list of User Stories for the next Sprint, it is important to know how much resourcing is available. For example if you have 5 people in your team but one is away for a week, you have 5×5 + 4×5 = 45 person-days which should match your estimated Sizing for this Sprint.
The Agile Scrum
The Agile Scrum is a daily process which ideally happens once the team has assembled in each morning. The Scrum is run by the Scrum Master.
The Scrum Master will ask each team member in turn to give a brief overview of their User Stories which they haven’t started, are in progress or have been completed (see also the Kanban post).
The Scrum Master will typically update JIRA (or which other tracking tool is used) to keep track of progress and adding any flags ore items which may require addressing.
It is very important that the Scrum be kept to 30 minutes max.
The Agile Sprint
An Agile Sprint is typically a two-week period in which User Stories comprising a Sprint have been completed.
It is normal for User Stories to roll between Sprints if they have not been completed.
At the start of a Sprint all User Stories (except those in-flight from the previous Sprint) will be in the “Not Started” list. During the Sprint User Stories will progress into “Awaiting Elaboration” if that is required, then “In Progress”, then “Awaiting Acceptance” and finally “Done”. More on the lifetime of a Sprint in a later post.
During a Sprint the burn-up rate (progress) can be reported upstream to Stakeholders.
The Agile Retrospective
One a Sprint has been completed and closed it is very useful to hold a Retrospective – typically a 45 minute session.
Before the Retrospective, agile team members should write down (e.g. on a post-it) one, two or three things that went well, and the same for anything which needs improvement.
For example “Cross-team collaboration went really well” or “I underestimated the time required to proof-read documents from a 3rd pty”.
The Scrum Master should take the highlights from the Retrospectives and feed them back into the process to track any actionable items.
It is important that the Retrospective has outcomes rather than just being a meeting or chance to complain about something.
Stepping back for a moment – it is of course very important that all the agile materials and processes come together resulting in continuous delivery whether technical or business related.
Each Sprint should in effect contribute to the delivery of an Epic.