How do you do Scrum in a regulated environment?
30-01-2013A failed Sprint Review
01-04-2013In my Intense Certified Scrum Master training, we dive in right away with using Scrum to learn Scrum. People swim a bit at the beginning until they start to figure things out. That’s intentional – as people see they can get past the chaos and quickly create something cool and useful, that’s when they learn deep down in their gut that Scrum really works.
I always ask for suggestions to improve the course, and item which has come up repeatedly is a glossary of terms. So here it is! 62 Scrum-related terms in 50 words or less:
| Term | Meaning |
| Acceptance Criteria | Tests which must pass for the Product Owner or customer to consider the Story accepted. The Team should verify these before submitting a story to the PO for final approval. Acceptance tests help ensure External Quality. Product Backlog Items can usually be mapped to one or more Acceptance Criteria. |
| Agile | A movement for finding better ways of developing software. Scrum and Extreme Programming are two leading examples. Others, such as Kanban or Lean Startup do not define themselves in the Agile tradition, but are based on compatible values and principles. |
| Agreement | The basis for planning and completing work in Scrum. Examples: the Defintion of Done, the Selected Product Backlog, the Sprint Contract, and the Definition of Ready. |
| Artifact | Something that archaeologists find. Often used to describe the documents produced by a project management methodology. Scrum artifacts are all living documents to guide and monitor work. |
| Best Practice | Some consultant’s solution to someone else’s problem. Is your context similiar enough to the original for the solution to be applicable to you? Questionable. Will you do better by coming up with you own solution? Usually. |
| Ceremony | A fancy word for a meeting or routine process. |
| Chickens | Deprecated term for people interested in the results of project, but not 100% commited to its success (e.g. due to conflicting priorities). Chickens can be very disruptive to the Team. Spectators (who might become hooligans) is considered more politically correct metaphor. |
| Committment | A core value of Scrum which should not be interpreted to mean that the Team is expected burn itself out trying to achieve unrealistic goals Sprint after Sprint after Sprint. |
| Daily Scrum | A daily opportunity for the team to inspect and adapt on their progress throught the sprint. 3 defined questions to recognize that they need to talk to each other (preferably right after the Daily Scrum). |
| Definition of Done (DoD) | An agreement on what ‘this Story is done,’ actually means. Helps assure Internal and External Quality for each Story. Often expressed as a checklist to be completed before submitting the Story to the P-O. The Definition of Done applies to individual Stories, not to Tasks or the overall release. |
| Development Team | An interdiscipinlary team with all the skills necessary to get a problem from wish to done. |
| Done (for a feature) |
A binary state. Either a Story is completed according to the Definition of Done, or not. |
| Done (for a product) |
A judgement call by the Product Owner. At the end of a Sprint, if the P-O believes that it’s worthwhile to release, the product should be releasable. If it’s not, there is undone work which should be addressed at the level of the Definition of Done in future sprints. |
| Estimate | A Team’s best guess at the size, complexity or time involved to convert a PBI into a piece of finished functionality. An estimate is not a commitment. |
| Extreme Programming (XP) | An Agile approach to Software Development, often applied in conjunction with Scrum. XP defines the engineering practices needed to produce quality software in an iterative environment. |
| Forecast | A Team’s best guess at how much finished functionality it can deliver by the end of a Sprint. The team is normally expected to respect all the terms of the Sprint Contract. |
| How-To-Demo | A short workflow for demonstrating to the Product Owner that the functionality has been implemented correctly. Also useful to limit scope creep while implementing a Story. |
| Impediment | Anything which slows the team down or prevents someone from working. Although the Scrum Master is charged with removing impediments and all Scrum meetings provide regular opportunties to recognize them, impediments can be identified and eliminated at any time by anyone. |
| Increment | An additional slice of customer visible value, delivered by the end of the sprint. The latest increment must integrate with the previous delivered increments to form a working whole. |
| Must | Absolutely required, or else! The Product Owner must attend Sprint Planning 1, otherwise the meeting cannot be held. |
| PBI | Product Backlog Item |
| Pigs | Deprecated term for those people 100% commited to the project at hand. Always refers to ScrumMaster and Development Team. If it does not refer to the P-O, this is a sign of dysfunction. Players (on the field), those directly involved in the game, is considered a more politically correct metaphor. |
| Priority | Sequence – which item comes first, second, third, etc. The term priority is deprecated because a) it contains emotional overtones and b) two items could have the same priority, but must a have a unique place in line. |
| Product Backlog | The single source of requirements for the product under development. It consists of functional and non-functional requirements. It is not used to plan work or define intermediate artifacts, like a specification, which have no value for the customer or user. |
| Product Backlog Item (PBI) | An entry in the Product Backlog, consisting of a description (often a user story), a sequence position, and an estimate. Often enriched with Accepance Criteria and other useful information. A PBI is not a specification, but rather a reminder to hold a conversation shortly before implementation. |
| Product Owner | A servant leader who guides the Development Team to produce customer visible value. Sometimes called the Voice of the Customer (or User), the role represents all interests outside the Development Team to the Team. |
| Quality, External | Did you build the right thing? Does it perform the way the customer or user wants and expects? Acceptance tests strive to ensure external quality. |
| Quality, Internal | Did you build it right? Does the product behave the way its creators intended? Unit tests ensure that a program continues to behave correctly, event after modifications have been made. |
| Quality, Overall | Also known as ‘Fitness for Use.’ A state achieved incrementally in Scrum. The Product Owner decides when this has occured by calling for a release. |
| Release Burndown Chart | A tool for visualizing to progress of the team toward a medium term release goal. The y-axis is the sum of the estimates in the Product Backlog. When a PBI is Done, it’s estimate can be deleted from the Burn Down chart. |
| Release Planning Meeting | Team and Product Owner come together to refine the Product Backlog. Although timeboxed, there is no decision to be taken at the end of the meeting, so it is often a useful preparation for SP1. |
| Retrospective | The Team (and anybody they invite) reflects on how they worked to identify improvements for the next Sprint. |
| Ritual | Fancy word for a meeting or routine process. |
| Scrum | A simple, team-based approach to solving complex problems. A mindset based on a culture of transparency and regular cycles of inspection and adaption. A popular approach for developing software. |
| Scrum Master | A servant leader who helps Product Owner and Development Team perform better. Coaches & Facilitates. Removes impediments. Sometimes called the voice of common sense. |
| Scrum Team | All three roles together make up the Scrum Team. Sometimes called the Whole Team |
| Selected Product Backlog | The subset of (by definition top priority) PBIs that the Team reasonably believes it can complete during the Sprint. (Often mistakenly called the Sprint Backlog). |
| Sequence | A unique ordering. First, Second, Third… The product backlog is sequenced. |
| Should | Highly recommended. The Scrum Master should be present at the Daily Scrum (but the meeting goes on without her, and it may be difficult for her to do her job properly if she does not attend). |
| Sprint | A timeboxed period for completing work. A Sprint consists of planning, doing and review, both of the results and of how the Team worked. Maximum timebox is 30 days. 2 weeks is common. All forecast work should be Done by the end of the Sprint. |
| Sprint Backlog | The Selected Product Backlog, enriched with a technical concept and a task planning. The Sprint Backlog represents the Team’s concept for achieve the goal set during Sprint Planning 1. |
| Sprint Contract | The agreement between Product Owner and Team at the beginning of a sprint: Time (Sprint Duration), Cost (Team Composition), Quality (Definition of Done) and Scope (Selected Product Backlog). If the team should fail to deliver on any aspect, it should fail on Scope. |
| Sprint Planning | Sprint planning addresses 2 questions: What and How. The meeting is divided in two halves, SP 1 and SP 2 for addressing these questions |
| Sprint Planning 1 (SP1) | The Product Owner and Team agree on what will be developed during this sprint. The PO defines priorities, the Team estimates how much is doable. So both parties influence the final agreement: the Selected Product Backlog and the Sprint Goal |
| Sprint Planning 2 (SP2) | The Team decides how to solve the probelm accepted in SP1. The result is a technical concept and a task planning, often in the form of a task board. |
| Sprint Review | The Team and Product Owner come together to inspect and adapt the product, based on Done functionality. They will review what has and has not been completed, and reflect on how to change the Product Backlog before the next sprint planning |
| Stoos | A movement for finding better ways of managing organizations that was inspired by the Agile movement. Stoos seeks to catalyze a lasting change in how businesses do business. |
| Story | Term often used to refer to a Product Backlog item, even if not formulated as a proper User Story. |
| Story Point (SP) | A unit to guage the size of a PBI relative to other PBIs, estimate the size of a project and monitor progress. Something like a kilometer for code. |
| Task | The Team uses Tasks to plan the work in the Sprint. When all Tasks associated with a Story are completed, the Story should be Done. Typically a Task represents a goal for the day, or something smaller. Most coaches no longer recommend estimating tasks in hours. |
| Task Board | A visual representation of the work to be completed in the Sprint. Typically 4 columns, organized in swim lanes, per story: Story, Tasks Waiting, Tasks in Progress, Tasks Done. Often supplemented with Burndown Charts, Impediments and other information useful to the Team. |
| TDD Test Driven Development | Also known as Red-Green-Refactor. 1) Write a failing unit test (red) 2) Code a first draft to turn the test green, keeping all other tests green). 3) “Refactor” to create an improved a final draft. TDD improves productivity by reducing misunderstood requirements, rework, and escaped errors. |
| Team | An older term for the Development Team. Because effective collaboration between P-O and Development Team is associated with high performance, Product Owner, Scrum Master and Development Team are now refered to as the “Scrum Team.” |
| Technical Debt | A consequence of poor engineering practices which make a program difficult to modify. Like financial debt, technical debt must be paid off or technical bankrupcy follows: Throw the program away and write a new one. |
| Timebox | A constraint to prevent a complex situation from degenerating into chaos. All rituals in Scrum are timeboxed. |
| Undone Work | Can you release the product at the end of the Sprint? If not, there is undone work. Typical examples include: regression testing, usability testing, customer acceptance tests. The less undone work you have, the more predictable your release dates. |
| Unit Tests | Automated tests written by the Development Team to assure Internal Quality. Unit tests enable Refactoring and provide an essential safety net, so that changes and fixes do not introduce new errors. |
| User Story | A people centered approach to defining requirements with a standardize form: As <some role or persona> I want <some value> so that I can achieve <some goal or purpose>. The word ‘user’ should never appear in a User Story. |
| Velocity | A unit to guage to speed of development and estimate the completion date of large projects. Usually expressed as Story Points per Sprint. |
| WAP | Widely adopted practice, often used together with Scrum, but not part of Scrum — you may do it or not if you feel it applies to you. Examples include Story Points, User Stories, Definition of Ready. |
| Whole Team | An XP term for the Scrum Team |
| Work in Progress (WIP) | Work that has started but has not yet been completed. Lots of WIP is associated with poor performance and inability to get things done. Scrum limits WIP by limiting the number of stories in the Sprint. Teams can further limit the number of Stories in progress during the Sprint. |
