Whether you work for a digital company or a charity, are an experienced Project Manager or a university student, you may have heard of ‘Scrum’ or ‘Agile’ but may not know that much about what they are or how to apply these frameworks to your projects. As The Scrum Guide says: “Scrum is simple to understand but difficult to master.”
Here at The Cogworks HQ, we’re all about progressing and encouraging positive, result driven training for our staff because we want the best possible performance outcomes for both staff and clients.
Over the past few months, four of our London staff have attended the two-day ‘Certified Scrum Product Owner’ course taught by Martine Devos, a master in the field who has coached over 30,000 people in Agile.
Head of Content Agnes tells us more...
A month ago, I was offered the awesome opportunity to attend the training which was very exciting for me personally and for my career in the digital world! While the course itself is too comprehensive to explain in a blog post and being new to the Agile world, I thought I’d share a short overview and decode four main aspects of Scrum that were brought up during the training for others new to or interested in Scrum.
But before we dive in, I think it’s worth defining the different roles involved in the Scrum Framework as that was the first aspect that intrigued me. A Scrum team only includes: the Scrum Master, the Dev Team and the Product Owner and each one of these roles has a defined set of responsibilities.
So, what is a Product Owner and how is it different to a project manager? Well, firstly there is no project manager in a Scrum Team! Martine explained that the Product Owner is a key stakeholder in the project, but he (or she) is not meant to impose things on the team, he is here to motivate everyone and set out a vision for the project. He is ideally always available and possesses great communication skills.
The next question then was: what is the role of the Scrum Master? The Scrum Master should be a facilitator that removes all barriers that get in the way of the development/production team and ultimately surrenders control of the projects to the Dev Team and the Product Owner.
For this article I want to focus on a few simple scrum concepts that I have heard spoken about in the office, but didn’t know exactly what they were.
Sprint? You mean like Usain Bolt?
Firstly, what’s a sprint? A sprint is the heart of Scrum. In short, it’s a time-box period in which the work gets done.
Part of our discussion during the class was about the ideal length of a sprint. Some people prefer one month sprints, some believe in two week sprints, Martine suggested the ideal length was 1 week, but in the end, it is all about what works for you and your project.
A question that a lot of people ask is, if a task is not finished at the end of a sprint, is it a fail?
Martine says in fact it’s the opposite! If the length of your sprint does not allow the time needed to finish a task, it means the estimation was possibly not accurate in the first place, which is OK because an estimation by nature is never 100 per cent accurate!
The key then is to ensure that your estimation process is refined over time to make sure that the user stories or tasks are broken down in a way that they can indeed be finished within the allowed sprint time.
Estimations - let's get to the point
Another interesting topic during the training was what’s the point (pun intended) of estimating in points and how do you do it?
This was a topic I was unfamiliar with, as my role at The Cogworks running the content team does not expose me to the way that the project management and development team estimate their work.
Within the content team, we only estimate tasks in hours. We populate content every day and are pretty confident we know how long each task takes, even if the projects differ in size. However, I am starting to work closer with the development team at The Cogworks, and am noticing that it’s a lot trickier to estimate requirements for complex web projects, so in this case I realise the purpose of using a different system.
Martine explained it’s about estimating the effort more than the length of the task, i.e. you don’t need to know if it will take an hour or six hours, you just need to estimate the complexity in comparison with another task’s complexity within the product backlog. However, if the same kind of task has been estimated several times by the developers, they may know how many hours it will take but usually, points shouldn’t be converted into hours otherwise you’ll lose the purpose of point estimation.
Ah product backlog…a buzzword I have heard but never really understood. Basically, the backlog is a prioritised list of things that need to be done within a project. It’s not a fixed list of things, it continually evolves and changes throughout the project’s lifespan. During the course we learned how to build and manage a backlog - which is an essential responsibility of the Product Owner.
As a <Project Owner>, I want to be able to <write User Stories>, so that <I can keep my job>
User stories was my favourite module because it tackled an interesting topic: Companies doing certain things that are trendy without really knowing why and if there is a purpose to it. Currently, Scrum is a go-to trendy framework, so often writing ‘user stories’ can become something people do just because it’s ‘cool’.
Have you ever written user stories and wondered why you were doing it (apart from ‘because my manager asked me to’)? Martine explained to us that not all projects need user stories, for example - a home appliance company making a fridge would write a user story such as: ‘as a fridge, I want to be able to keep food fresh so that people don’t get food poisoning.’ It’s a little obvious, right?
A user story is usually in this format: ‘As a...I want…so that…etc.’ But the key lesson here is that you only write them if you can define what exactly the purpose will serve.
In the end, no matter what company or industry you work in, if you handle complex projects Scrum could be beneficial for you and give you the mindset needed in order to successfully deliver your project.
There are plenty of classes you can attend but if you really want to learn from a master, we highly recommend Martine Devos’ class. She is passionate and enthusiastic about what she teaches and she she will even go the extra mile and give you tailored advice for your projects.