Strategic Transformation | Web Design

The Team structure

This perspective of this article is from the technical view of implementing Scrum, and not about how to transform an organisation to embrace a flexible, collaborative, self-organising, and fast changing environment. Setting up an Agile CoE (Centre of Excellence) will be covered separately

One of the principles of Agile is the idea of self-organising teams. Unlike a traditional team, a Scrum team doesn't have a team leader to make the crucial decisions and solve all the problems. Instead, the Scrum team as a whole decides how to overcome the challenges.

A Scrum team consists of a Product Owner who usually represents most stakeholders, Devs (Development Team), and a Scrum Master. There are also other stakeholders who are called upon as and when needed.

Dev Team - The Devs are NOT only the software engineers, and in some cases may not even be these at all. Yes it's true that software engineers translate user stories into a product increment, but in the context of Agile, 'Devs' refer to those who develop the User Stories to their ultimate form.
The Dev team will be multi-skilled but roles can be interchangeable with the goal of the team becoming cross functional.
Product Owner - The PO turns stakeholders requirements into stated features or needs (called user stories). The PO should understand the vision of what is trying to be achieved and therefore decide on what has to be developed by a Development Team and what the priority is.
The most effective Product Owner is one that is empowered by the Stakeholders; they understand and can drive the vision; they can make fast decisions and have the authority to do so; and are also capable of saying 'No'.
Scrum Master - The SM is a facilitator that manages cooperation and team working in the Scrum Team. The SM encourages Agile practices and improves efficiency in the team as well as the organisation.
Stakeholders - A stakeholder is anyone with an interest in, or has an influence on the product. These will help the team to discover, develop, release and support the product. As these people will usually be unfamiliar with Scrum, the Scrum Master will ensure that they know what the deliverables and artifacts will be, the ceremonies or meetings they need to attend, and what is wanted from them.
Stakeholders may get disillusioned if what is demonstrated in the Sprint Review is not what was expected but it should be explained that this 'failure' is what the ceremony is designed to catch.

Fig. PO, Dev Team and SM will interact with the stakeholders, though it's the PO who is accountable.

Defining the work to be done

There is a hierarchy of understanding which begins with the Theme. A Theme is very high level and should act as a North Star guide for activities across the organisation. As the work breakdown structure develops, agile requirements break down further and further.

Initiative
Epic
User Story
Task

Initiative

One level of detail down from the Theme, an Initiative is also a very high level statement of business value, and a collection Epics that drive to a common goal.

Epic

An Epic is piece of work that can be broken down into smaller tasks called 'user stories' or 'stories'. It allows work to progress in smaller pieces whilst maintaining progress towards a common objective.

User Story / Story

A user story will focus on people / the customer, on what needs to be done, and why. The format is below:

As a [user role], I want [ability or feature of the product] because [the benefit/function of the feature].

It's a very short sentence written from the perspective of a specific stakeholder (there may be user stories for different stakeholders) a and will give the reader an instant understanding of the value that can be gained by doing the work. It doesn't need lots of detail. The principle of agile is 'just enough', and a user story acts as a placeholder, for follow up on the detail later.

Task

Tasks break down user stories or other items in the backlog to a more granular level.

Fig. Agile work breakdown structure.

The User Story / Story

The user story creates understanding of what needs to be done or a software feature from stakeholder / user perspective.

As a [user role], I want [ability or feature of the product] because [the benefit/function of the feature].

If the format is not followed there will be risk that implementation is not done correctly.

Common User Story mistakes

Too many stories - These are great for understanding features from each stakeholder's perspective, but there are also other ways of recording what is needed. These could be things like complicated interactions, processes modeling, andlow fidelity and high fidelity UI design.

Anonymous User - This is something I've seen more often than not. Rather than stating 'As a user...', it's crucial to understand just who this 'user' is in order to fully understand their need. No more mythical 'users', please!

Large user stories - These are sometimes so big or ambiguous that they can't be delivered in a short time scale. In likelihood, the user story is actually an epic which hasn't been broken down. A user story needs to be clear, achievable, and testable.

User Story hand off - The traditional method of development sees diligently written Requirements Documents provided by the BA and business teams to the developers. The problem with this is that the developers often don't understand the requirements. User story hand off is the same. Instead, user stories should be defined in conjunction with the development team.

I've seen these mistakes far too frequently. In fact it's more usual than unusual to see them. Clearly, organisations have some way to go before they can be considered truely Agile.

Fig. "These aren't the droids we're looking for".

Scrum events

Scrum is comprised of Sprints, which are fixed periods of time, each of which are typically between one and four weeks. The point to this is accomplish tasks in incremental pieces. Because each sprint is so short, it allows projects to cope with uncertainty and changing requirements.

Backlog Refinement - Everything that needs to be included in the product or project has to be refined, or better understood so that the effort can be estimated.

Sprint Planning - At the beginning of a Sprint the team determines which of the refined items from the product backlog they will work on during that Sprint.

Daily Stand Up - Involving up to 11 people including the Scrum Master and Product Owner, the daily stand up should be no more than 15 minutes. In it will be communicated progress and impediments. Answers to the three questions are shared -

What was done yesterday? What is planned today? Are there any blockers?

Instead of this, the team can simply talk about what they want to achieve today. It's a chance for team members to share information and help out others.

Sprint Review - At the end of each Sprint, the review covers all that was done and what was not done in the previous Sprint. This will then feed into the next planning session.

Sprint Retrospective - This provides a chance for the team to to discuss the challenges encountered in the previous Sprint, and what went well or otherwise, with the aim of being to improve the next sprint.

Implementing Scrum