8 Scrum practices you are probably underevaluating

At OneOffTech we believe in Agile approaches and use Scrum company wide for internal projects and with clients.

Running a small team with different projects active in a single sprint makes us reflect more on what we would like to achieve with our clients. Over the past 6 months we observed that some key roles and practices of Scrum were not always clearly defined from the beginning in each project. Sometimes the definition of done, or in other words when a task can be considered completed, was not properly defined or even extremely difficult to define.

To empower the transparency principle of Scrum here are our 8 most underevaluated practices.

1. Appoint a company wide scrum master

This sounds obvious as your company might be already committed to applying Scrum, but the Scrum Master is the key person that must ensure your company follows the Scrum framework in its essence.

Beside ensuring that proper Scrum events (e.g. planning, retrospective) takes places, the Scrum Master should help every team member to improve self-management and focus with respect to the Scrum theory and practices, e.g. being open, respectful, focused or when apply more/less courage.

Having a single known Scrum Master within the company helps ensuring that each Team member knows who's gonna manage the Scrum events (i.e. meetings) and help the team grow.

The Scrum Master serves the Developers and the Product Owner, but also removes barries between stakeholders and the Team.

The number of Scrum Masters in a company depends on the size of the team and quantity of products. We found that having only one helps in the initial adoption of Scrum and keeps the process light. In case of large projects it is helpful to have a dedicated Scrum Master in the initial phase.

What our Scrum Master is doing:

1. Refine goals and issues with the Product Owner in a timely manner. Changes in a product can happen daily, so from time to time it is necessary to ensure that all the issues are aligned with the latest goals
2. Handover to a team member the role to govern a sprint planning. After conducting two or three planning ask a team member to conduct the meeting on your behalf, this will help each member develop skills related to being transparent and committed
3. Help writing the goal of the sprint before selecting the issues. To ensure transparency within the team ask the developers to define the goals of each project/product the sprint and let the Product Owner validate it.

Who Should be Doing What in a Sprint?¹ is a great reminder at the specific tasks of the Product Owner and the Scrum Master.

2. Appoint a Product Owner

Independently from the product being internal to the company or a work for a client you must have a Product Owner² as:

• Defines and communicate the Product Goal;
• Create the Product Backlog;
• Order the Product Backlog;
• Ensure that the Product Backlog is transparent, visible and understood.

The term product is on purpose general as the context of the company defines what a product is. It could be a software, a website, a part of a website or a consultancy for a client.

We are often asked if the Product Owner should be an employee of the company or, in case of client work, a client employee. The answer is: it depends on the commitment of the client. The Product Owner must be very committed and active during the process and our experience suggests that is not always the case. A member of own company might be in a better position to ensure continuity and transparency of the project.

If the client is deeply involved then a good approach could be ask the client to appoint a person as the Product Owner. If so within the company can be a delegated Product Owner for ensuring cohesion.

If no prior Scrum experience, clients may underestimate the effort and based on this observation we suggest to consider clients as stakeholders and inform them weekly via small review meetings. This ensures that the client and the team stays on the same track.

3. Do not underestimate the definition of done

An activity can be done or not done unless you observe it.

Scrum is based on measurable increments toward the product goal. What are those measurable increments accounts for the definition of done, which practically means when an activity can be considered finished and outcomes presentable to stakeholders (during or before the sprint review).

Defining what done means is mainly a Product Owner problem since they have the best visibility of the goals, but in practice it is a collective endevour of the Team to ensure that all activities/tasks completion is understandable and understood.

While preparing items in the product backlog, take time to describe when an item can be considered completed. An example could be writing some bullet points as acceptance criteria. What to write in those bullet points depends on the type of task and product.

For software development:

* [ ] _place expected manual tests or conditions to assert_
* [ ] Unit tests are present and covering the changes
* [ ] Test deploy can be done

For document production:

* [ ] Artefacts produced are stored in _location_
* [ ] Artefacts are reviewed and validated by someone else
* [ ] _Other criteria to discuss and agree_

4. Set a sprint goal

Before picking tasks it is important to define the goal of the sprint for the product(-s) the team will work on.

The sprint goal sets the objective of the sprint as identified by the team and for the team. the Sprint Goal serves the product owner to ensure transparent communication with stakeholders and to the developer to ensure proper selection of the backlog items to pick.

The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog.³

Although the sprint goal should not have an and³ we found out that it can be necessary, from time to time, as there might be unrelated changes coming from stakeholders. This should be clearly exceptions and the team should reflect on those ands during the retrospective.

5. Naming your sprint is hard

Should be a technology problem. Isn't it?

Depending on the tool a sprint can have a name, commonly Sprint followed by a number or Iteration followed by a number, and a start and end date.

Some tools might not have the concept of Sprint. In those cases you should give a name/title to the closest concept in that tool, e.g. a Milestone in GitHub/Gitlab or a board in Trello.

We found that the name can contain a progressive number, but should reflect the year and start date:

Sprint-{YEAR}-{COUNTER} ({STARTING_DATE}) 

Where

• {YEAR} is the current year, e.g. 2021
• {COUNTER} is the progressive counter starting from 1 at the beginning of the solar year, e.g. 12
• {STARTING_DATE} is the first day of the sprint in YYYY-MM-DD format, e.g. 2021-06-07

6. Ensure that everyone can pick tasks to do

Estimating tasks is hard. Sometimes you finish all the planned tasks before the sprint ends. In this occasion the developer should be free to pick-up a new task from the product backlog.

To ensure that a task can be selected check at least the following conditions:

1. The description is understandable
2. The definition of done is clear

If any of the two is lacking the developer should raise immediate concerns towards the Scrum Master and/or the Product Owner.

When writing a task always consider taking 5 minutes more to ensure the previously mentioned conditions are met. This will help in case backlog refinement cannot be done in advance for all tasks.

7. Backlog refinement

Tasks can easily pile-up and so your backlog becomes a gigantic mess.

A cleaner product backlog makes it easier to spot unrelated tasks, unnecessary ones and bigger goals:

1. Do not break bigger tasks earlier. You might want to make sure all tasks are as small as possible, but doing so you might break a bigger task into too many small pieces that have circular dependencies. If you are unsure that a task can be divided in smaller issues let it be tackled in its entirety and work with the team during its development to break it down;
2. Do not split bigger tasks that you're not tackling within two sprints. If the team comes from a Gantt based workflow it is common to try to plan deeply for tasks that will only be tackled after four sprints. Leave those tasks as general and refine them during the sprint before they can be worked on. This will ensure they are still relevant;
3. Remove duplication. Check duplicated issues earlier;
4. Title should be descriptive. Ensure that the tasks listed have a descriptive title that summarizes the goal of the issue.

8. Scrum board vs Kanban board

There is no board in Scrum.

It is common to say that you are using Scrum and present a board with tasks organized in columns and define it as the Sprint. In reality Scrum does not define states for what's in a Sprint because everything should be addressed as it was planned to do so. The Sprint Backlog serve as a plain list of tasks[^1].

A plain list is often not acceptable as the management wants to understand what is the status of each task and what is still not touched. This is when usually the labels To do, In Progress appear.

Provocatively, what does To do mean if the list is composed only of items you want to accomplish? So far we don't have an answer, but we do know that at some point the labels discussion took the stage. This might be because of influence of platforms like Trello and boards being spread on various tools for project management.

On the other side Kanban⁴ define the process in terms of a board where cards (i.e. tasks) are moved between states. It must be said that there is no backlog, so all cards starts in a To do state and moves as progress is made.

Mixing the two approaches is definitely possible and there might be reasons. While doing so developers might not reliably apply labels. Daily Scrum (aka standups) quickly become a better way to know the status of a task. If the daily scrum is the only source of updates this can become a bottleneck and your attention should switch to document the tasks' progress via comments.

Bonus: Start small, you're not creating a roadmap

A client will always ask for a Roadmap or a Gantt of the activities no matter how you passionately explain them your agile way of working.

Roadmaps do not reflect the core concepts of modern product development which account for uncertainty, discovery and errors.

That said all projects has a beginning and an end and so do products (remember the definition of product depends on what your company is doing).

Our approach was to give general milestones, usually aligned with Sprint timing. You can see this as a set of expectations with respect to the timeframe of the project.

The article Escaping the roadmap trap⁵ by Emil Kabisch shows various other methods to deal with a roadmap under agile methodologies.