Getting started with Agile
- James Seabrook
Agile Setup Principles
Agile Framework Definitions
Initiative - top level/ includes at least one epic - this may be introduced in future
Epic includes at least one story
User Story includes at least one task
Tasks belong to a story or can be separate but are at development level
Sub-tasks are only necessary when a task needs to be split up into smaller units of work
Definition of Done
A definition of done is very important. Normally it would be the completion of the work to the end, with QA done and bugs removed. It is an important definition to get right and should be discussed and agreed with the entire team.
Steps to Find Your Definition of Done (With Examples and Workflows) | Planio
Epic
An epic is a collection of stories pertaining to the same goal/functionality. An epic can be large or small depending on the requirements and can contain as many or as few user stories as necessary. An epic does not have to fit into a sprint however individual user stories should be planned to be in a sprint.
User Stories (or simply Stories)
A user story is a way of describing in sufficient detail for developers a user requirement. It is usually generated by the product manager or somebody in an equivalent position. The job of the development team is to create smaller sub-units of the story (called tasks and sub-tasks) which are allocated a certain duration.
To summarise, every story should
can and probably should be in an epic
be estimated in story points (time or effort points depending on decision made, however story points have compelling advantages as they are seen as an expression of effort only whereas duration comprises of many factors)
have at least one task which can be measured in duration (days)
Sprint
Every sprint (usually 2 weeks) should contain a number of stories which are planned to be completed within the sprint period, subject to deviations and other factors. The output of the sprint should be released, where stories fulfil the definition of “done”.
Once in a sprint the user requirements should not be added to or enhanced by anybody; they should only be elaborated.
Everything which is “done” should be merged into the main branch for the project (development/project specific branch depending on the decision made).
A sprint review should be held at the end of the sprint containing releasable functionality. The aim of this is to ensure that product owners/stakeholders have an insight into what as been developed and allow amendments to be made as necessary and as soon as possible without major refactoring,
Adding epics and stories
Adding epics is the first process defining the breakup of the entire project into functional/strategic parts. There should be at least one story within each epic but generally it’s a series of stories which contribute to the functional journey.
User Story and Epic for the Win (With Examples) - Product Management (christianstrunk.com)
Epics, User Stories, Themes, and Initiatives: Key Differences | GBKSOFT
Sprint Planning
Aim is to work out which stories are able to be done within the sprint. Also to be able to give to the stakeholders something tangible to look forward to, considering any blockers which might curtail the expected delivery.
Stakeholder Reporting
Consider adding initiatives (for the board members / stakeholders visibility) which is a collection of epics at a much higher level.
Epics, Stories, Themes, and Initiatives | Atlassian