An introduction to Scrum

You might want to know what Scrum is, or you’re using Scrum and having some problems, or you just to learn more about it.

This introduction to Scrum is a mixture of the Scrum fundamentals, so pretty much what you get in the Scrum guide, mixed in with real-life experiences from within a digital agency.

I’m hoping by describing Scrum this way you’ll be able to build up a picture of what Scrum is if you’re new to it.

But also gain an understanding of what it’s like in the real world versus assuming it all works just like the Scrum Guide describes.

I’ve been working with Scrum for quite a few years with varying success and some total failures as well. These experiences have all been in the digital agency environment, which, in my opinion (no research to back this up) is one of the hardest environments to implement Scrum.

This is because we move from product to product and working with new clients all the time. It’s a constant loop of re-education, new outside influences and brand new products to develop.

On the plus side, you learn a heck of a lot, and it keeps the job super interesting and challenging all the time.

I’m going to cover the following, so feel free to skip to the section that most relevant for you.

1. What is Scrum (feels like a great place to start)
2. Is Scrum Agile, and what’s the difference?
3. Why use Scrum, and where can you use it?
4. What are the ceremonies within a sprint?
5. Why do you need these ceremonies?
6. What is a sprint and how do you pick a sprint length
7. What are the roles in Scrum and do these work when working with a client
8. What are the main challenges when using Scrum
9. Some extra sites and content for further learning

‍

What is Scrum?

Here is an out the book quote to start with as I like how it encapsulates what Scrum is.

Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

Now if that sounds a little robotic, here is another way to describe it. For me, Scrum is another way to deliver a project or build a product through short sprints (typically 1-2 weeks in length).

By planning the work in short sprints, it allows the team to focus on what’s really important for the end-user.

It works great when you don’t know precisely what is needed as the work can be broken down into sprints so you can build the product chunk by chunk.

Or in project terms, if you have a large project, it’s tough to plan everything up front, so keep the long term plan high-level and then plan in detail every two weeks.

Now if you like a few stats and were wondering how Scrum came about, here’s a high-level timeline of how it all happened.

Visually Scrum is pretty simple to describe as well and the diagram below is essentially these 5 steps.

1. Scrum is pretty simple to describe as you can see in the diagram below. It's essentially these five steps.
2. You start by creating a backlog, which is all of the ideas and features that could one day be part of your product or service.
3. You then take the highest priority items from your backlog and plan them into what you can achieve in the next sprint.
4. Now you start to build that product while every day having a stand up with the team to discuss your progress, plans for the day and any help needed.
5. Halfway through the sprint, you look at the high priority work for the next sprint to make sure you have everything ready in what's called a refinement session.
6. At the end of the sprint, you review your work and have a team retrospective to discuss what went well, what didn't and what should you start and stop doing in the next sprint

Is Scrum Agile and what is the difference?

Scrum is an Agile Framework, and Agile is a mindset is the simplest way I like to describe it. Agile, means able to move quickly and easily and in product development terms its about continuous improvement, empowerment of the teams, release regularly and value-driven prioritisation of work.

The Agile Manifesto which was created in 2001 but can be tweaked depending on what your products and services are when it comes to working software over comprehensive documentation.

This is merely saying get your product or service in your customer's hands as early as possible!

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan
5. 
   

The term Agile though has been used in all sorts of ways over the years, whether that's to describe a process at a company, or as a stick by clients to beat their suppliers with when they want to change their minds over and over again "I thought you said this was an Agile project!"

Scrum is called an Agile Framework as it promotes decision making through observation and experimentation over detailed planning, which is called empirical process control. The empirical process is made up of transparency, inspection and adaption.

The framework or the structure of Scrum allows this through the short sprints of work (typically 1-2 weeks), retrospectives (end of every sprint) and then the regular improvements made because of this.

‍

Why use Scrum and where can you use it?

You can use Scrum for multiple projects and product types. It was created with software development in mind as the team who created it needed a better way to build complex software.

Your projects don’t have to be complicated to use Scrum though.

You could even Scrum to plan a holiday! Start by brainstorming all of your actions you need to book and plan a holiday (the backlog).

Then plan your priority items into a sprint (time-boxed to 1-2 weeks).

You could have daily stands up to check in on progress (over breakfast) Mid-sprint take a look at what you need to work on in the upcoming sprint, so refine your backlog.

At the end of the sprint review what you’ve completed and achieved and what can be improved for the next sprint.

In this scenario, Scrum out of the box/book works really well.

What are the Ceremonies Within a Sprint?

The ceremonies are what make up the sprint within the Scrum framework.  

The below descriptions assumes a team that have the capabilities to build a digital product, but this could be a marketing team, HR, design only though, it really doesn’t matter.

To make Scrum work, you must make sure these ceremonies happen and at the same time each sprint.

This allows the team to continuously improve how they’re run as well as the outputs created. Like anything in life, the more you practice at something the better you get at it.

Sprint Planning

When: Day one of the sprint 

Team members required: The full team, so typically the Scrum Master, Engineers, QA, Product Owner, UX & Product Designers (The development team)

Duration: Typically an hour if the correct preparation has has happened in the previous sprint 

Purpose: Sprint planning sets the vision or goal for the sprint so the full team are aligned from day 1. So what do we want to achieve by the end of this sprint?

Prior to this meeting, the backlog of stories will be updated into the current priority order by the Product Owner and the high priority stories already refined to an agreed definition of ready.

The development team then discuss each story in more detail so they can collectively estimate it or assign complexity (Story points). You can add the required subtasks to the story.

The team continues to assign the stories until they’re at capacity. These chosen users stories then become the sprint backlog

Things to note: 

1. It’s the doers who decided on the stories effort or complexity and what they can commit to within a sprint, not the Product Owner or Scrum Master.
2. This is an opportunity for any final questions before sprint backlog is agreed. Make the most of it, so sketch out ideas, push back if don’t have what you need. If you don’t do the refinement sessions before this, you’ll find you can spend hours in sprint planning. They’ll be far to many questions you won’t have items, sprint backlog items are blocked and ultimately you’ll start a sprint that is set up to fail!
3. Continuous refinement  prior to sprint planning through conversations and examples is the key to a successful sprint planning ceremony..

Daily Stand-ups

When: Every day of the sprint apart from day 1 where you do sprint planning. Usually first thing in the morning.

Team members required: Development team and typically the Scrum Master. Product Owner being present is advised.

Duration: 15 minutes, but sometimes adjusted if agreed by the team

Purpose: Quick updates from the Development team to share progress, plans, and any issues or help needed. Used to keep the team all in sync on everyone’s progress, encourage transparency and a time to ask for help!

Things to Note:

1. If you’ve agreed at the start of the project the stand up will be 15 minutes, then stick to 15 minutes. It’s not a status meeting, so should be brief and ideally a little fun to start the day in a good frame of mind! If a team member can’t join (late in) start without them.
2. The stand-up time should never move unless agreed by the whole team.
3. The stand up is run by the development team, not the Scrum Master. The Scrum Master is there to hear of any impediments and support the team and Scrum process

Story Refinement

When: Once mid sprint 

Team members required: Scrum Master, Product Owner and Development team 

Duration: Typically an hour

Purpose: A chance for the team to come together and review the highest priority items in the backlog not yet worked on. The Product Owner presents the latest stories and explains the reasons why they’re top of the backlog and what they expect the new items will need to achieve.

Things to Notes: 

1. Refinement isn’t just the Product Owner speaking, this is a chance for the team to ask questions, potentially adjust the item in terms of how it could be built.
2. Use this time to draw up potential solutions and make sure there is lots of discussion on the need and approach.
3. Focus on what’s really important and needed for the next sprint first so you don’t get side tracked, then work your way down the backlog. As well as asking lots of questions to fully understand the need, also think about what could stop you working on it. There is nothing worse than being blocked in a sprint as it disrupts everything.

Sprint Review

When: Last day of the sprint 

Team members required: Scrum Master, Product Owner, Development team and project stakeholders

Duration: Typically 1 hour

Purpose: Sprint review is a time to showcase the work of the team. They can be in a casual format like “demo Fridays”, or in a more formal meeting structure.

This is the time for the team to celebrate their accomplishments, demonstrate work finished within the iteration, and get immediate feedback from project stakeholders.

Remember, work should be fully demonstrable and meet the team’s Definition of Done to be considered complete and ready to showcase in the review.

Things to Note:

1. Agree early with the client and then team the format of the sprint demo. It can be a round table demo if that’s suitable, or some clients it has to be a more formal presentation. Check early to avoid any last-minute rushes.
2. If it takes the team longer than 30 minutes to an hour to prepare for the demo, there is probably something wrong. The works completed should always be in a ready state so if this is not the case, discuss why in the retrospective.
   
   

Sprint retrospective

When: Last day of the sprint 

Team members required: The development team, Scrum Master and Product Owner

Duration: Typically 1hr

Purpose: A chance for the team to review what went well, what didn’t in the last sprint and what should they start doing in the next sprint. The retrospective is critical for continuous improvements and ongoing engagement of the team.

Things to Notes: 

1. This should be the team only, so no management or stakeholders. This is to allow the team to speak freely and focus on how they can improve.
2. Take turns to facilitate the ceremony, so don’t just rely on the Scrum Master. Keep it fresh by trying different retrospective approaches.
3. It’s fundamental that the learnings from the retrospective are implemented. Not doing so will result in the team quickly losing faith and the improvements curve will decline.

‍

Why do you need these ceremonies?

One recurring issue raised by teams or management new to Scrum is could you not be spending more time doing the work versus attending these ceremonies?

If you look at this in simple terms, yes would have more time for the work if you don't attend them but overall you'll produce less in the long run for these following reasons, but there are also many more.

No Sprint Planning:

• The individual overestimates what they can complete as they're working on their own.
• They get blocked as the work they've chosen to work on has dependencies they weren't aware of.
• They're not working on the highest value items for your customer.

No Daily Stand-Ups:

• Decreases team collaboration
• Increase risks of problems not being raised earlier enough
• Less likely to solve problems as a team

No Sprint Refinement

• Future sprint work will likely get blocked by outside dependencies.
• Misunderstanding of the work required resulting in re-work
• Highest value items for your customer not being worked on

No Sprint Review

• The team have no focus to work towards
• The team take less responsibility for their work as it's not being presented to anyone.
• They feel less valued as they're not able to show their work and do not receive feedback

No Sprint Retrospective

• No opportunity for the team to self evaluate and improve.
• Team morale is slowly impacted, as no improvements are made.
• Decreases team collaboration and increases silo work and approaches

‍

What is a Sprint And How do you Pick a Sprint Length?

In the Scrum Guide, a sprint is a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort.

A new Sprint starts immediately after the conclusion of the previous Sprint.

So a sprint is simply a time period that is fixed, and within it, the planned work is performed.

It's called a sprint as it's a short time period. A Scrum sprint can be as short as a week or as long as a month.

The most common in the digital industry I work in is a 2-week week sprint as with Software development this is enough time to produce something that's worth reviewing. For design sprints, we typically do one week.

The reason it's important to time box a sprint is so you can then create a sprint goal and estimate how much work you can do in this time. It gives the team focus and a target to work towards.

A common mistake by teams and clients is to think that everything must be finished in a sprint, and what you agree to in Sprint planning is exactly what you'll get.

This simply isn' the case; it's about showing what you have completed and in some cases what you haven't. The key is to learn why you didn't finish a sprint backlog item and improve for the next Sprint.

Or if you've met the sprint goal, then you've delivered what you set out to do.

To pick your sprint length, just decide what a reasonable amount of time the team need to produce something that can be reviewed at the end of each Sprint is.

Plus how often you would like to get feedback. Feedback is really important and useful. Hence we use 1 or 2-week sprints.

I wouldn't be tempted to do a month sprint without good reason as you lose that connection with your client and its users.

‍

What are the Roles in Scrum and how do These Work when Working with a Client?

The most straightforward description is that the Product Owner decides on what the development team work out the how and the Scrum Master helps achieve the how.

The below describes some of the key responsibilities of the team members who make up the Scrum team.

You'll see there are two roles Scrum Master and Product Owner, then the Development team.

The Development team are the actual doers, the ones who work out how to do the work and then actually do it.

This team could be made up of any number of roles depending on the product or service you're creating.

n my case in a digital agency, it's typically iOS, Android or Web Engineers, User Experience Designers, Automation Testers and UI Designers.

The point of having this one Development team is it highlights they're one team and they're responsible for what's produced.

They need to be empowered to make decisions and have the right environment to create the highest value items for the end-user.

Creating the right environment is crucial, and the perfect example is the retrospective ceremony.

This is for the team only, and any stakeholders or non-team members are not allowed to attend unless invited by the team.

SCRUM MASTER: Protecting the Scrum process and preventing distractions

• Responsible for helping the team deliver work to the Product Owner or Client
• Makes sure the team can meet its commitments by removing any impediments they face, including managing dependencies, escalating blockers that they cannot remove themselves 
• Facilitates process & meetings (eg Reviews, Stand-Ups, Planning, Estimation, Scheduling, Prioritisation) 
• Makes sure the team is fully functional, productive and improving quality 
• Shields the team from distractions and interferences (including the Product Owner) 
• Enables close cooperation across all roles and functions, removes barriers 
• Responsible for reporting progress, including producing standard outward-facing artefacts 
• Manages Product Owners expectations of the team 
• Responsible for keeping time and quality requirements
  
  

PRODUCT OWNER: Determines what needs to be done and sets the priorities

• Voice of the Stakeholders, represents the business 
• Manages stakeholder relationships, comms & expectations 
• Accountable for the vision, scope, and scale of the product 
• Defines key features of the product & success criteria 
• Continuously refines requirements 
• Sets delivery schedule by managing the backlog – creates and updates the release plan, including prioritisation 
• Accountable for the project success 
• Decides on the release date, content and budget 
• Accepts and rejects work in the sprint reviews 
• Takes advice from the team on Backlog Dependencies 
• Single point of contact for the product (including New requirements Prioritising backlog items)

DEVELOPMENT TEAM: Takes on and determines how to deliver chunks of regular increments

• They have to break down the requirements, create tasks, estimate and distribute them. In other words, this means that they have to create the Sprint Backlog.
• They have to perform the short Daily Sprint Meeting.
• They have to ensure that at the end of the Sprint potentially shippable functionality is delivered.
• They have to update the status and the remaining efforts for their tasks to allow the creation, of a Sprint Burndown Diagram.
  
  

When working within an agency, you have to be considerate of a client's internal governance and processes.

Quite often, these go against Agile principles and the Scrum framework, so patience is required and lots of education.

Don't expect to transform a clients way of working from day one, as you need to be considerate of their internal ways of working which might not be quite ready for an iterative approach like Scrum.

Use the initial project set up to run Agile games alongside education and knowledge-based workshops to gauge the level of Scrum knowledge and clearly define the roles.

We often role share the Product Owner role between one of our Product Owners and a brand expert on the client-side.

On paper, this goes against the Scrum guide, but it works well for these reasons.

• It utilises the knowledge of our clients business, and it's customers from day one
• Our internal PO's knowledge of the brand's customers and business is built up over time so reduces risk of not working on high-value items
• The client-side Product Owners has the environment and time to build up their Product Ownership skills and capabilities  
• We're able to train the client on how to be a Product Owner, so eventually, they can take this product forward without us.
• 
  
  

Within an agency, the Scrum Master role often has to overlap into more traditional Project Management when it comes to reporting.

In Scrum, you should only track things that ultimately improve the team and provide value for the customer.

Like the education of the client-side Product Owner above, the same needs to happen with client-side reporting.

You’ll find that often they’ll be a lot, but this is typically because;

• It’s how it’s always been done on the client-side
• Lack of trust as this is a new relationship and a new product, so the pressure to succeed is high
• The client has multiple management layers to report up to
• New to Scrum and don’t yet understand the value of producing outputs focused only the user
  

Again education is the key approach by having a 'why' focused workshop on communication and reporting.

Asking why you need this report but also what value will it bring, plus what the team could be doing if they were not creating it quickly opens the eyes of the client.

They'll be some reporting that must be produced for someone senior in the clients business.

Use this as an opportunity to change this report type slowly, and it's content over time until it's something that works for you and the team.

In summary, you need to show flexibly and be considerate of the client's current systems and processes which may well likely have been in place for years.

Enjoy the challenge of how you can improve and educate on the journey.

‍

What are the Main Challenges When using Scrum

These are a few challenges when implementing Scrum within an agency. None of which aren’t fixable over time but very important to be aware of when considering Scrum or planning it.

Outside influences

This can be within the company you work for or on the client-side. There are always influences which could be projects, people or processes that can negatively impact the Scrum team.

When planning the team always discuss dependency management and what could stop the team from producing high-value work.

External processes

Linked to the above, but one of the most significant risks to Scrum is external processes that don’t work hand in hand with Scum.

The classic example is other projects working in a Waterfall manner and can’t work at the pace a Scrum team can.

Or a prolonged client-side UAT phases which go against producing a shippable product every sprint.

Lack of understanding

We’ve made the mistake of assuming the client understands the fundamentals of Scrum and the actual why.

You need to push to find out how much they know, then use Agile games and bringing them into the process to help them.

It’s easy and more comfortable for someone to say they know something rather than they don’t, so understand this and bring them on the journey.

Stakeholder management

This is tough as quite often they’re not involved day to day with the Scrum team or even end of sprints for the review. They can appear like magic with a different view and direction halfway the project and can completely derail what’s been produced so far.

This is why you must do stakeholder mapping and don’t stop digging until you really find out what the stakeholders want from the project. Look at ways to get them engaged and in some cases excited about the project through the education of the client-side Product Owner.

Team availability

If you’re part of a small company, then one of the issues with Scrum is team availability.  

Scrum out of the book often talks about the team being 100% time-wise, but in reality, team members have to deal with pitches, problems with live products and various other legitimate requests for their time. I’ve experienced all of these in the past, but it does get easier as your company grows.

There isn’t a single perfect answer to this when you’re a small agency, but expectation management and transparency really helps.

As a Scrum Master, you should continuously be on the lookout for potential requests that may come to your teams. Continually check by asking the team, other teams, management etc. You can then start to mitigate the risks around a last-minute request for time, and just as importantly plan for it within a sprint.

Long term planning

Often clients and management think that if you’re working in an Agile way, then there isn’t any planning. In reality, there is more planning than in a Waterfall project.

The difference with an Agile project is you plan in enough detail when needed, rather than everything at front. For example, you have a daily stand-up in Scrum, this is daily planning, but it has a reason and its beneficial.

You plan every two weeks for a new sprint as it gives you a short term goal to work towards that you can then test with your users. This reduces the risk of spending to much time working on something that isn’t of value to the user.

This approach is followed for long term planning, use it when you need to, but only if you need to. In our case within an agency long term planning is needed to shape what a product could look like, when could we potentially have a releasable product, or just to help us prioritise, size (high-level) and do dependency mapping.

The issues with long term planning are without it being explained correctly in terms of the why, it can sometimes be taken as a given by your client, as in this is what they’ll definitely get in 3 months time.

So focus on the why and the benefits just as much as potentially what could be produced.

Client availability

This one is a problem because if your client is not engaged and available, you’re just storing up problems for X amount of sprints down the line. This one is a relatively easy one to solve, and it begins from day one of the project.

We call this phase mobilisation, and one short workshop within it we hold with our clients is named ‘Team Availability’. We spend time sharing information on where our team are each day (could be work from home days) holidays and availability, including when the ceremonies happen.

We then do the same with our clients, so when will you be in our office vs theirs, holidays booked etc. We also combine this with explaining how we’ll be successful and what that means when it comes to their involvement.

The key is transparency and knowledge sharing, which allows you to set expectations with them from day one.

No Agile tools

By this, I mean that tools are not in place for the sake of having a tool. For some projects, you can have Post Its as this is enough, but others you do need may need Jira, Confluence etc. What you don’t need in Scrum is a Microsoft project plan 😬.

Make sure the tools serve the value you’re striving for and don’t dictate the process. If they do, then work out how you can mitigate by simplifying their use or proving the negative impact they’re having on productivity. Showing the result in the teams of time and then the cost of this is a great way to do.

Fixed scope contracts or mindset.

If you have a fixed scope contract, there isn’t much point in using Scrum or at least using it for what it was created for. Fixed scope means you have to deliver what you say you’ll provide at the start.

This doesn’t allow for innovation or most importantly working on the highest value items for your client's customer. If you have to use Scrum for fixed-scope projects, then you have to remove the client's ability to be able to prioritise the work and iterate on what you've created (change requests).

It also increases the documentation dramatically and prolongs any engineering work until all documentation is signed off.

Essentially you’re squeezing Waterfall into Scrum.

Lack of client coaching

Lack of client knowledge when using Scrum is first down you to as you have to coach this.

You can’t make assumptions on their knowledge and even if they’re experienced at Scrum, having a team coaching session is a great ice breaker and useful for building team morale and the environment.

So you’re responsible for making this happen as if you say to your client you’re using Scrum, then you should be able to coach it.

‍

Some Extra Sites and Content for Further Reading

There is so much great content out there on Twitter, YouTube and the internet, it’s almost inexcusable not to know about Scrum if you’re starting out. I’ve put a few I really like below.

Mike Cohn who run Mountain Goat Software is my favourite for if you’re new or experienced with Scrum. He provides so much free content through his blog, newsletters, books and on the site itself. He has really clear and easy to follow video courses as well. His site is www.mountaingoatsoftware.com

A couple of my favourite books by Mike are Agile Estimating and Planning  and Succeeding with Agile: Software Development Using Scrum

Jeff Patton is probably most famous for his approach called User Story Mapping. Again lots of great content on his website and his book User Story Mapping: Discover the Whole Story, Build the Right Product  is fantastic. His site is www.jpattonassociates.com

For communities, you can look at the Slack group Hands on Agile. This group has a really wide range of experienced people from all over the place. It’s used to post useful content, ask questions, find new Scrum or Agile related events.

The video is a great introduction to Scrum as it covers the flow and the basics. Click here to watch

‍