Scrum is incomplete by design and additional practices will be essential to develop a product. The Scrum Guide includes the following important related statements:
“Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.”
“The Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory.”
“Various processes, techniques and methods can be employed within the framework. Scrum wraps around existing practices or renders them unnecessary. Scrum makes visible the relative efficacy of current management, environment, and work techniques, so that improvements can be made.”
Here are some commonly used complementary practices that many Scrum Teams find useful. These are not best practices as even the best practices may not be appropriate in all environments. Instead, these are good practices which may or may not help a Scrum Team depending on their unique context.
| Scrum/Kanban Board | A physical or digital board to visualize information for and by the Scrum Team, often used to manage Sprint Backlog. Helps to make information visible which may help to better manage it and reduce reporting overheads. |
| Visualise Dependencies | A dependency is a potential impediment that may slow down or stop a Scrum Team. Visualise them so they can be better managed to reduce their impact. |
| User Stories | A short, simple description of a feature told from the perspective of the person who desires the new capability. Historically user stories were deliberately kept informal, written on index cards or sticky note and arranged on walls to facilitate planning and discussion. |
| Burn Down Chart | A chart which shows the amount of work which is thought to remain in a backlog. Time is shown on the horizontal axis and work remaining on the vertical axis. As time progresses and items are drawn from the backlog and completed, a plot line showing work remaining may be expected to fall. The amount of work may be assessed in any of several ways such as user story points or task hours. Work remaining in Sprint Backlogs and Product Backlogs may be communicated by means of a burn-down chart. See also: Burnup Chart |
| Velocity | An indication of the amount of Product Backlog turned into an Increment of product during a Sprint by a Scrum Team, tracked by the Developers for use within the Scrum Team. |
| Planning Poker | Planning Poker can be used for team based estimating with a consensus approach. It can lead to improved estimates by unleashing the knowledge of the full team. |
| Scrum Team Charter / Working Agreement | Define who we are, what matters most and how we use Scrum. Other details included may be how we make decisions, things we always agree to do or not do etc. Can help build the Scrum Team and reduce conflict |
| Spike | A timeboxed activity that is carried out in order to deepen an understanding of something ahead of a full implementation. Spikes focus on gathering information and finding answers to a questions, rather than producing a usable Increment. |
| Daily Scrum – Stand Up | If you are running the Daily Scrum in-person, doing it standing up can help to keep within the 15 minute timebox. |
| Daily Scrum – Focus On Sprint Backlog | Place the focus on the work rather than the people in order to help ensure the Daily Scrum is used for planning rather than reporting. |
| Teams that Finish Early Accelerate Faster | Scrum Teams that fail to deliver what they forecast for a Sprint may be criticised. This may lead to a feeling of failure and demotivation which may lead to reduced value delivery. Leaving some slack when planning the Sprint may eliminate this keeping motivation higher. |
| Product Backlog Refinement Workshop | Define a regular timeboxed meeting to focus on Product Backlog refinement. |
| Definition of Ready | A formalised and shared understanding by the Product Owner and the Developers regarding the preferred level of description of Product Backlog items introduced at Sprint Planning. |
| Product Roadmap | A high-level, strategic plan, that describes the likely development of the product over the next period of time. It may help the Product Owner to keep their stakeholders aligned, make it easier to coordinate the development of different products and increase transparency in order to manage customer expectations. |
| Product Vision | A view of the future. Describes the purpose of a product, the intention with which the product is being created, and what it aims to achieve for customers and users. |
| Business Model Canvas | Helps organizations conduct structured, tangible, and strategic conversations around new businesses or existing ones. Can be used to define the product strategy. |
| Lean UX Canvas | To help teams frame their work as a business problem to solve (rather than a solution to implement) and then dissect that business problem into its core assumptions. Define those assumptions into hypotheses. Design experiments to test our riskiest hypotheses. |
| Product Wall | A highlight visible single source of truth to help you manage your product effectively and increase transparency around your product. May include your Product Backlog, Roadmap, Burdown chart of other useful information. |
| Change For Free | Allow the customer to add a PBI if they remove one of equal cost/size/complexity, thereby achieving higher value for the customer. |
| Happiness Metric | Measure and focus on the improving the Scrum Team’s happiness. Happy teams are motivated and will deliver increased value.. |
| Fix As You Build | Fix defects as you find them during a Sprint. |
| Continuous Integration | A software development practice where Developers regularly merge their code changes into a central repository, after which automated builds and tests are run. |
| Continuous Delivery | A software development practice where code changes are automatically prepared for a release to production |
| DevOps | DevOps is a set of practices that combine software development and IT operations to enable faster and more reliable delivery of software. |
| Test-Driven Development | A software development practice where developers write tests before writing the code. TDD helps to ensure that the code meets the requirements and is of high quality. |
| Pair Programming | A software development practice where two developers work together on the same code at the same time. One developer writes the code while the other provides feedback. |
| Mob Programming | A software development approach where the whole team works on the same thing, at the same time, in the same space, and at the same computer. |
| Code Reviews | A software development practice where developers review each other’s code to identify defects, improve quality, and ensure that the code meets the requirements. |
| Refactoring | a software development practice where the code is improved without changing its external behavior. |
| Behavior-Driven Development (BDD) | A software development practice that emphasizes collaboration between Developers and stakeholders to create software that meets business goals. BDD involves writing automated tests that define the behavior of the software in a way that is understandable to stakeholders. |
* This list will be extended and enhanced regularly.