In this article, part of my series explaining better ROI from software development, I’d like to start looking at Scrum. Given the size of this subject I am spreading across multiple parts. This is the first part.
A brief note on intended audience; this article is not intended as a training guide for Scrum. There are a lot of resources out there. Much better than I could every produce. This is much more an introduction from a Return On Investment perspective aimed at business leaders.
I have a Scrum.org certification as a Scrum Master. I strongly believe in Scrum. I have an obvious bias towards it.
With reference to my Agile article, Scrum is a methodology consisting of a series of rules that provide guidance on how to develop software in an Agile manner. Scrum is probably more business plan than operational procedure.
I will provide a primer on Scrum during this article (with subsequent articles look at the benefits). If you feel you understand Scrum well enough already, then feel free to skip this article (I’ll never know).
If however you are new to Scrum, then I would recommend reading the Scrum Guide. It isn’t a long read, it takes about 30 minutes. It does a much better job than I can do.
The article is my summary of that Guide. My summary should not be taken as the text book definition - I’ll take a few liberties to try and keep this in summary format.
Unless otherwise noted, all quotes in this article are taken from the Scrum Guide.
The Scrum Guide defines Scrum as:
“Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.”
The guide goes on to describe Scrum as a framework that consists of:
I’ll not specifically highlight the rules in this primer – otherwise I’ll just be re-writing the guide. Some details of the rules will be included in the summaries of the Roles, Events and Artifacts.
Scrum defines a number of roles for a Scrum team. These roles effectively replace all others (such as Project Manager, Business Analyst, Senior/ Junior Developer, Tester, etc). The Scrum team is intended to be cross-functional with all the competencies need to produce the product.
There are three roles within the Scrum Team:
“The Product Owner is responsible for maximizing the value of the product and the work of the Development Team”
Think of the Product Owner of being who is in charge of what is being developed. They have the authority to decide what work is done and in what order.
The Product Owner works very closely (ideally full time) with the Development team to represent the business and its needs as well as to provide a business response to Development team questions.
Be careful not to think of the Product Owner too much as a manager.
Scrum is clear that the work is a product of the team, not an individual. As such it sees all members of the development as being equally responsible.
As such Scrum doesn’t allow for differing roles (or rather titles) within the team – for example, programmer, designer, tester. Those titles would indicate that an individual is only responsible for a narrow part of the work.
By defining everyone as a Developer, Scrum expects the team to accept full responsibility and each individual to do everything they are able to ensure that the team succeeds (rather than just doing their “bit”).
Team size is limited to 3-9. Below 3 there will generally not be enough capability to deliver the changes without outside assistance. Over 9 there will generally be too much coordination activity to be effective.
The Scrum Master is often misunderstood. They are often portrayed as someone standing over the team with a whip – this is completely wrong.
The Scrum Master is there to make sure that the Scrum process is understood, and adhered to. They are also a servant-leader to the team helping the team to identify and remove impediments to progress.
A Scrum Master can be many things within a given day – a teacher, a cheerleader, a councillor, an advisor, a trouble shooter, and an evangelist.
Scrum defines a number of events:
All Scrum events share one thing in common – they are a timebox. They all have a maximum duration. This is important to understand as they define a cadence to the actual work.
The Sprint is the main timebox – everything else lives within it. A Sprint in generally 2-4 weeks long and it is the time in which work is performed on the product.
You are always in a Sprint. There is no gap between Sprints.
This is important as you then understand that all design, planning, testing, etc are encapsulated within the timebox.
At very basic level; at the start of the sprint the team should be deciding on what they are to work on in the period. During the Sprint the team work on it (and only it). At the end of the sprint, they shall have completed to the work to a shared definition of “Done” (see below).
The Sprint is the only timebox that cannot be shorted (unlike the other events). I can be cancelled, but this should be seen as a traumatic and rare event.
The Sprint Planning event occurs at the start of the Sprint – without it the team don’t know what to work on in the Sprint.
The Product Owner will have a list of changes, improvements, fixes, etc (see Backlog below). They will have a view on the priority of those items.
Sitting as a Scrum team, decisions will be made based on priority and estimated effort - ultimately what items the team believe can be achieved within the Sprint.
This is physiologically a very important step – they are given the responsibility to act appropriately in determining their own workload. As I’ve covered in previous articles, this is a considerable motivational factor.
Once the items have been decided upon, the items are broken into tasks that the team believe are required to complete the item to the definition of “Done” (see below). Not everything needs to be defined in detail at this point – just enough to get started.
The Sprint Planning is timeboxed to up to 8 hours for 1 month sprint. It is generally shorted for shorted sprints.
The Daily Scrum is a daily meeting in which the team synchronised their activities for the last 24 hours and plan for the next 24 hours.
This is timeboxed to 15 minutes. It is intended as a lightning meeting for the team to understand where they are in the workload, understand if there are problems and plan ahead.
The timebox in this case plays an important role (as it does with all the Scrum events, but possible more so in the Daily Sprint) – it keeps everyone focused on what they are meeting for, do it efficiently and effectively, then get on with more productive activities.
You may have heard of these as “stand-up” meetings before – in which the theory is that if everyone is standing, they are inclined to get on with it.
An important note; the Daily Scrum is for the team. It is not a status update to management. This should be seen a collaborative, open conversation between peers working together for a shared goal.
At the end of the Sprint, the Sprint Review is an opportunity to review the work completed within the Sprint. This should be a meeting including the Scrum team and any appropriate Stakeholders.
Ideally the work should be demo’ed with feedback gathered.
Taking a step back a second; I consider all changes to be based on theory. Until you have implemented the change and applied it, you cannot be certain that a theory is correct.
You may have a “theory” that the new functionality will save/ make considerable money. But until it is in use and providing real evidence, it will continue to be nothing more than a theory – no matter how confident you are in it.
The Sprint Review is a great opportunity to review some of those theories. Looking at what has been delivered, maybe the theory was off – but maybe there is somewhere new this leads.
Always see the Sprint Review as an excellent opportunity to look at where to go next. This is then fed back into the Backlog (see below).
The Sprint Review is timeboxed at 4 hours for a 1 month Sprint. Shorter Sprints will have shorter reviews.
The Sprint Retrospective is an opportunity for the Scrum team to inspect itself and create an improvement plan.
It is generally held at the end of Sprint (although it doesn’t have to be).
This meeting should be just for the team. This is for them to look at what worked well, and what could be better. This maybe tools, techniques, processes, relationships, etc – anything that can be considered a help or a hindrance for the next Sprint.
Out the back of the meeting, the team will generally have an idea of what they would want to tweak for the next Sprint.
The Sprint Retrospective is timeboxed at 3 hours for a 1 month Sprint. Shorter Sprints will have shorter reviews.
The Scrum Artifacts are:
The Product Backlog is a list of the changes that are intended for the product. These changes can be improvements, fixes, or new features.
This is living breathing list that will change over time. Items can be added and removed at any time.
It is the responsibility of the Product Owner to maintain that list – including prioritising the items on it.
Nothing should go into the Sprint without it having gone through the Product Backlog first.
Note that while it is called a “Product” backlog, it will depend on the team and environment if there are separate backlogs per product, a combined for all products or a mixture.
The Sprint Backlog is a subset of the Product Backlog that shall be worked on during the Sprint.
Items are transferred from the Product Backlog to Sprint Backlog during Sprint Planning. Items not completed by the end of the Sprint should be returned to the Product Backlog (leaving the Sprint Backlog empty) – these may then be added again at the next Sprint Planning or be bypassed in favour of higher importance items.
The Scrum team use the Sprint Backlog to focus their efforts during the Sprint. All work during the Sprint should come from the Sprint Backlog.
This is the new version of the product – it is the combination of work prior to the Sprint and any additional changes produced during the Sprint.
The Increment should be to the point defined by the definition of “Done” (see below).
The Increment is what is reviewed in the Sprint Retrospective.
Technically, the definition of “Done” is not an artifact by the rules of the Scrum Guide.
I include it here however as I feel it is useful to cover.
The definition of “Done” is pretty much as the name suggested – it is a shared understanding of what it meant by Done.
Traditionally, it has been very easy for a developer to see Done as it works on their machine. They pass the work onto the test team (or someone further down the chain) and move onto the next activity. If there was no mistakes made then this would be fine. Software Development however is a tricky and complex task and it is generally inevitable that any size of work will either have defects or misunderstandings. The further that makes it away from the developer (time and people), the more expensive it is to resolve.
The definition of Done is generally all the tasks necessary to have the Increment ready to release – so this would include testing and stakeholder approval. It is the responsibility of the team to get any change in the Increment to that definition. Any change not reaching that definition by the end of the Sprint is, by definition, not-done and thus goes back into the Product backlog.
I believe the above should serve as enough of a primer for the upcoming articles.
In the next article, I’ll cover some advice when considering Scrum.