Agile cheat sheet – The manifesto – http://agilemanifesto.org/
Scrum – All bold / italic test in Description area has a corresponding section
| Term | Description | Comparable too |
| Done / Definition of Done | One of the most over used and debated words in Agile is the word ‘Done’. Done in some organisations means ‘Dev Complete’ or ‘Testing completed; etc… Done in true Agile terms means that the work has been delivered; for web platforms that would be to live. It would not be to staging as there is a possibility that the User Story may not pass UAT and therefore need more work doing against it. Simplest view to take is Done = When its live. Though the definition of Done may change depending on the organisation / team. | Completed / Delivered / In production / Dev Complete- Dependent upon the organisational definition |
| Push | Scrum is an upfront estimated workflow and the team picks up new User Stories from the backlog of work or the furthest point from ‘Done’. This is referred to as a ‘Push’ system of pushing work items over the line to a Done state. Velocity is the metric used to help guide the amount of work the team commit too. | |
| Ceremonies | Release planning, Sprint Planning, Showcase / Demo, Retrospective | Meetings |
| Artifacts | User stories, Tasks, BDD feature files | NA |
| Release | A release can constitute of a single or multiple Sprints. Has a dual meaning, can be used to describe just a grouping of Sprints or an actual release to production. | Milestone |
| Sprint / Iteration | Time-boxed period of work by a delivery team, commitment made and estimations made at the start of the sprint for the number of User Stories that can be delivered within this period. Length varies from team to team / business-to-business, 1-4 weeks, most common is 2 week Sprints. Term Sprint / Iteration terminology will be used interchangeably. | View as a micro milestone |
| Feature / Theme | A description of a value-adding feature. Will be made up of a collection of Epics, User Stories. Good Agile teams align these to Releases so they blend seamlessly. | Large work item |
| Epic | A large User Story that cannot be delivered within one Iteration. Often if a User Story is larger than 60% of the Sprint it will be considered an Epic. What differentiates a User Story and Epic? Only its size, everything else is the same. An Epic needs breaking down into further User Stories to become viable for Sprint consideration. | Medium work item |
| User story / Stories | Key artifact that the team / individuals within the team work to deliver. A User Story should meet the INVEST Criteria (Independent, Negotiable, Value add, Estimable, Sizable and Testable). This must be deliverable within the Sprint time-boxed period. Stories are sized not using a measurement of time but relative sizing often using the Fibonacci scale (1,2,3,5,8,13, etc) referred to as Story Points or t-shirt sizes (S,M,L). User Stories should be written in a simple non-technical focused way. Often using personas to describe the desired functionality;As a marketing manager I want the homepage to display a banner with products that sell infrequently So that I can improve the products conversion rates.
User stories should convey the value being realised by not only team, but written so that business users can see the value add of the User Story independently of the other User Stories. | Small work item |
| Tasks | Individual tasks for the individuals in the team working on a User Story, these are associated to a single User Story (duplicates are frequent across multiple stories). Tasks can be technical, non-descriptive as it is only important that people delivering the story understand what the task means. | Micro work item, often not captured in other waterfall orientated methodologies. |
| Velocity | Velocity is metric of how many story points a team delivered within the last Sprint and used to help guide the team as to the amount of story points they should attempt to commit to in the next Sprint. | NA |
| MVP (Minimal Viable Product) / MMF(S) (Minimal Marketable Feature (Set)) | The MVP is the least possible collection of Features before a product can be considered to go ‘live’ to its customer.This is very much inline with ‘Lean Start Up’ which is not only applicable to start ups or new products but also existing solutions that require enhancements. Further reading, Google -> Eric Reis. | NA |
| Story mapping | A method of organising User Stories into a value driven grouping and supporting Vertical / Horizontal slices. | NA |
| Vertical / Horizontal slices | A method for splitting User Stories into a journey, not by page or by component, but a slice through a journey (i.e. from homepage to checkout on an Ecom platform). This may be loosely referred and often, incorrectly used in other contexts within Agile teams / businesses. | Use Case |
| Task / Kanban board | A board were User Stories / Tasks are visibly and visually displayed. Consists of vertical swim lanes that represent ‘state’ of the Task or User Story. Sometimes has a horizontal swim lane to group User Stories (not a recommended practice). Typical board may have Backlog, W.I.P (Work In Progress) and Done. Amount of vertical swim lanes varies from 3-7. | NA |
| Daily Stand ups | 15-30 min daily stand-up. Purpose is to refer to the work you are working on (User Stories on the task board) and what has been done in the past 24hrs, what you intend to do in the next 24hrs and if you have any impediments | NA |
| Release / Feature planning | Same as Sprint planning, but at a level above inclusive of Features and Epics. Should be aligned to business key dates (pre-team sizing the backlog of User Stories). | Milestone planning |
| Ceremony – Sprint planning | A meeting where the team reviews the backlog of work and the Product Owner presents the top priority User Stories to be delivered. If Epics are presented the Scrum Master will either refuse this on behalf of the team or give the team the opportunity to decompose the Epic into smaller User Stories. Unsized User Stories will either be refused or sized during this session. Average time to complete 1-4hrs. | Micro planning |
| Ceremony – Showcase / demo | Not a PowerPoint presentation, but a demonstration of the actual working software and a recap of the stories delivered. Feedback provided by the Product Owner and any invited Stakeholders (stakeholders identified by Product Owner prior to the meeting). All feedback to be considered by the Product Owner and the team during Release / Sprint planning.Average time to complete 45mins-2hrs. | Client / Customer demo |
| Ceremony – Retrospective | Time for the team to reflect on the previous Sprint, not only on the actual delivery, but also on the happiness, confidence of the team.Average time to complete 1-3hrs. | Wash-up |
| The Chicken and Pig |  | NA |
| Scrum Team | Is a collection of people who posses any required skills to deliver the desired outcomes. Typical team consists of a Product Owner, Scrum Master, BA, QA and Engineers / Developers. Though the shape of this team should vary at times to meet the requirements of the deliveries. Scrum teams should be sized 7 +/-2. Large teams of 10+ struggles to operate within Agile. If there are 14 people working on a product / project, split it into two teams and give each team a Theme / Feature to own and deliver. Agile teams are not responsible only for a part of the delivery (i.e. build or test or deploy) but every aspect, and should not be considered Done until there code is live. | Delivery team, but often separated by role / function in other approaches. |
| Product Owner (PO) / Product Manager | Own the direction of the Product, has the authority to make decisions on behave of the business, has financial control and autonomy. | Product Manager |
| Agile Coach | A person who coaches the principles / practices of Agile and often includes Scrum Masters. How to sniff a good coach? They’ll also manage a Scrum Team. Perceived as more senior to a Scrum Master. | NA |
| Scrum Master | Servant, Leader, Referee, Diplomat, primary concern is to remove team impediments and to enforce / guide the team within the boundaries of the framework (though Scrum is adaptive). Not to be confused with Project Manager. Technically in Agile an Agile PM is an oxymoron. A Scrum Master is not a Pig, not a team lead or responsible for delivery, they are there to empower the team to deliver. | NA |
| Burn down / burn up | A simple line chart that shows progress against the amount of User Story points or User Stories committed too, the amount remaining and the ideal line to meet the commitment deadline | Progress tracking charts |
| Project vs Product | Project has a definitive end point with a prescriptive set of outcomes, product is constantly evolving and therefore requirements change over its lifetime to meet customer needs. | NA |
Kanban
| Term | Description | Comparable too |
| Flow vs Rhythm | Kanban is a flow system as it is not time boxed and measures the throughput of work. Scrum is a Rhythm system that has a regular beat of time boxed periods (Sprints) and measures the either the throughput of User Stories or the points it delivers. Both approaches should have production smoothing techniques implemented. | NA |
| Pull | Kanban focuses on team members picking up the next closest Artefact near to completion. This is referred to as a ‘Pull’ system as you are pulling the next Artefact along to being completed. Kanban uses tight historical metrics for determining the likely delivery period of any given Artefact. | |
| Artefact | Though User Stories are often used, Kanban supports any artefact moving from one side of its task board to another (unlike Scrum). This could be a SOW, a code story, a checklist, etc… | Any artefact |
| Kanban board | See Task board under Scrum section | NA |
| Class of service | A grouping of Artefacts into classes that mapped against the priority of what needs to be delivered. Any number or given factors can be considered for classification, but once agreed should change very infrequently. An example would be 1-5 (1 being most important, 5 least important). Very powerful, but often not implemented due to lack of understanding of its purpose. | Very similar to ITIL / ISO SLA’s / Priority / Severity models |
| Cumulative Flow Diagram (CFD) | A area diagram that captures the flow of each pre-defined work state (Backlog, W.I.P, Done, etc…) over a period of time, offers a higher resolution of progress than a burn down. | Progress tracking charts |
ScrumBan
A hybrid approach and takes on many different shapes and forms. Often implemented because a team struggles with aspects of either Kanban or Scrum, but also can be used to enhance either approach (i.e. Cumulative Flow Diagrams in Scrum, User Stories in Kanban). Agile is an evolving model that will vary between each business, as Agile is meant to mould around business needs instead of being hyper prescriptive in its implementation / approach.
SaFE – Scalable Agile Framework for Enterprise
A mash up of both Agile and Waterfall, not recommended. May hear the term, but should be avoided highly unlikely its being used in any shape or form. Not to be confused with Bi-modal.
XP Practices
| Term | Description | Comparable too |
| Bill of rights | A list of responsibilities both individually, as a team and as a customer. | RACI |
| Peer review | A review of a User Story / artefact that’s delivered, not only at a code level but a demonstration of the code delivering the desired outcome as the User Story / Artefact describes. | Enhanced code review |
| TDD – Test Driven Development | An approach of writing tests before writing code. To successfully deliver a story all tests should pass. Associated to a User Story or Artefact. Writing Unit Tests is not the same as doing TDD. | NA |
| BDD – Behavioural Driven Development | Specification / requirements that is testable, often used to cover functional testing but mature teams / companies use BDD for describing all specifications. Written in simple business English construct (Given When Then, GWT’s), referred to as a scenario;Given my account increases its balance When I add $1 into my savings account Then I expect to see my balance amount increase by $1
Engineers / developers then write fixture code to pass the statement above. This approach removes ambiguity and moves testing away from being technically focused (Unit testing) to being more business / functional orientated. Best approach uses BDD and TDD. BDD is NOT a technical tool but a business (often BA owned) practice. | NA |
| Pair Programming | Two engineers (or an Engineer and QA) share a single keyboard, one drives / one witnesses, and they work on a single User Story / Artefact until delivered. This reduces the likelihood of errors, improved code excellence and is good for up-skilling team members. | NA |