Intro

Scrum teams operate in a process that highly benefits from certain ceremonies and necessities to be efficient and thus successful. Most teams should be able to perform the ceremonies without any additional overhead but if you work with Scrum teams long enough or see how several of them operate, you'll start to notice why these artifacts (in this case documents) are so important.

In most (if not all) Scrum frameworks you'll see a Definition Of Done (DOD) and Definition Of Ready (DOR). Their purpose is to set the expectations for everyone to understand when things are done or ready, so there is no room for miscommunication or missed expectations. The whole team has to set and respect the points listed in these documents.

You don’t have to think of them as something special or complicated. They are just a few points that have to be finished in order for a task/story to be considered done or ready. Below you can have a look at our set of rules and get inspired. Feel free to adjust these or experiment with them. It should give you a general idea of how we get things done and what might help your team.

There is one additional document as a bonus and that is our Estimation Flow. It is not something baked into the Scrum framework (like DOD or DOR are), but we find it very helpful, and thus we are sharing it with you.

Estimation Flow

It’s something that we created to get better at our estimations. It’s nothing fancy, just a very basic checklist. Generally, before estimating a task, the team should be able to answer questions about what needs to be done. Whenever you are not sure what story point amount to pick or what is the scope, it comes to the rescue.

These have appeared in our projects:

• Are there any new components/services that need to be created?

• How does it affect the state management or the database structure?

• Do we need any new BE endpoints?

• What needs to be tested (workflows, unit tests, integration tests, etc.)?

• Is build or deployment affected by this?

• Will it be feature toggled?

• Does it require any code refactor (model changes etc.)?

• Do we need to worry about some Search Engine Optimizations (SEO) here?

• Are changes in the API documentation (swagger) required?

• Should we extract some functionality (to a shared library/package)?

• Are changes in CMS needed?

• How do we handle errors (is there any failover mechanism needed)?

• Does it have the necessary architecture (cloud, hosting, domain, redirect, etc.)?

• Do we need to consider any 3rd party dependencies?

• Should this feature be optimized for performance?

You can create as many points as you like here, and you will notice which are the most helpful ones over time. Keep it up to date and don't be afraid to revisit it often if needed.

Story size

There should be a general understanding of what is the maximum size of a story in story points. If we are getting close to the maximum, it is usually a very good idea to split the story.

Reference Stories

We have a list of references to stories that allow us to imagine how much of an effort it is to work on something similar.

It can be a very basic list that looks like this:

• 1 SP example: <link to reference issues that have a size of 1 SP>

• 2 SP example: 

• 3 SP example:

• 5 SP example:

• 8 SP example:

Don't forget to revisit these after a while (a few sprints) to be sure you are not shifting too much or if you need to include some new references.

Definition of Ready

This helps the team understand and verify if the story is ready to be worked on. I like to say that a feature is usually as good as its assignment. The better you create the assignment, the more confident you can be that every member of the team has everything necessary to move forward in an effective and organized way.

User Story/Improvement Story

• The story is written in the issue description and adopts the following unified format:

• User Story

  • I, as a <role>, would like to <description of the functionality>, so I can <description of benefits after this story is done>.

• Improvement Story

  • Current functionality of <something> does <brief description of the current feature (ideally with a link to the initial stories)>. I, as a <role>, would like to <description of the new functionality>.

• Acceptance criteria are written, clear, and testable.

• The issue description is clear to all Scrum Team members.

• All necessary inputs, including Visual or UX designs, are provided, reviewed, and clear to all Scrum Team members.

• User Story is reviewed at Refinement meetings and all comments and questions are answered.

• The story is estimated in Story Points.

• If the story is too large, the team should consider splitting it into separate parts.

• If the story consists of multiple components/autonomous parts, it will be further split into separate stories which will be estimated individually.

• If any of the additional changes affect the scope of the task, they have to be approved and re-estimated accordingly.

• Scrum Team understands how to demonstrate the result of this story at the sprint demo.

Bug

• An issue is created and added to the Ready for Refinement section.

• During the Refinement, this issue is added to the current sprint/Ready for Sprint column by the Product Owner.

• The bug report contains:

  • A detailed bug description:

    • Write down all the steps needed to reproduce this bug.

    • Describe what the expected behaviour is.

  • More specific information (visual outputs, logs, environment):

    • Include screenshots/videos when needed.

    • Include the version/environment where the bug occurred.

• If the fix of this bug is not straight-forward, it is time-boxed and reviewed by the team.

• If a bug is discovered during User Story testing, it is added to that Story as a Story Bug.

Sprint

• All Sprint Backlog Items (SBIs) are estimated or time-boxed.

• All SBIs are ready according to DoR.

• Sprint Goals are clear and agreed upon by the entire Scrum Team.

  • Sprint Goals need to be SMART.

• The sprint consists of must-have items (related to the Sprint Goals) which should not exceed a predefined threshold (typically 50% of the velocity).

• The rest of the sprint contains bugs, improvements, nice to have items, etc.

• The capacity of the sprint has to be determined based on the availability of the team and the history of team velocity.

Definition of Done

It is a set of consistent criteria for each story or task to be considered done. It sets the expectation for the whole team for when we can move on and proudly say we delivered "this" part.

User Story/Improvement Story and Bug Report

1. API definitions have been updated.

2. All code tests are passing.

3. The builds and CI checks are successful.

4. The work has been peer-reviewed and approved.

5. Internal QA does not reveal any related bugs.

6. The code changes have been deployed in the target environment.

7. Acceptance testing passed with approval.

8. The related issue is closed by the assignee.

Sprint

• All user stories and tasks that the team has committed to, have been closed.

  • The only exceptions are stories or tasks that have been moved out of the sprint after a mutual agreement that has been reached as soon as possible after the start of the sprint.

• A Sprint Demo has been held and all finished stories have been demonstrated to the stakeholders.

• All Sprint Goals have been achieved.

Conclusion

The Scrum team is about achieving the best results over time, being efficient in what we do, and delivering the best value to the customer. If the team has the necessary support and space they can achieve great things. When working in such a team, remember that the ceremonies, documents, and rules are there for a reason, and that reason is that it helps the team to achieve the Sprint Goals. Feel free to pick what you like or give it a try and use things that work for us. Let us know in case of any related questions.