Scrum and Presentation Design – Part 1: Introduction to Scrum

Welcome to the first post in a multi-part series discussing the application of Scrum to Presentation Design. Now, most of you probably don’t know what Scrum is so this first post will provide a brief overview of Scrum. Then in subsequent posts we will see how we can use elements from Scrum when designing presentations.

What is Scrum?
Scrum is an agile software development framework.

Agile –adjective

  1. quick and well-coordinated in movement; lithe: an agile leap.
  2. active; lively: an agile person.
  3. marked by an ability to think quickly; mentally acute or aware: She’s 95 and still very agile.

Definition from –

Basically agile means the ability to change direction quickly, to be flexible. So when we talk about agile framework we mean a framework that enables a project the flexibility to change direction.

You see when we embark on a software project we do not know what the end result will look like. There is great uncertainty in the outcome and many external factors might change during the course of development, the most important one is the user’s needs. Others include new technologies might arise and different market conditions might exist.

Scrum is a tool that can be applied to software development to reduce those risks by applying an iterative process to the development that allows the project to change direction, receive input, learn from the past, review and improve. Iterations are called sprints.

Scrum ProcessImage Source: Wikipedia

Why use Scrum?
We touched on some of the reasons for using Scrum above. The main reason is to reduce the risk of the project. How do we reduce the risk? Basically we build products or services that users want. By incorporating continuous user feedback and short iterations we can easily change direction if the user changes his preferences/requirements.

How does it work?
Let us look at how Scrum works in more detail, the technical aspect of Scrum.
Scrum consists of three roles, three artifacts and three ceremonies
The three roles are:

  • Product Owner – responsible for the profitability of the product as well as defining the features and prioritizing them according to market value.
  • ScrumMaster – ensures that the team is fully functional and productive, responsible for removing barriers and makes sure the process is followed.
  • Team – a cross-functional (5-7 member) self-organized team.

The three artifacts are:

  • Project Backlog – a prioritized list of features required for the product or service.
  • Burndown Chart – shows the cumulative work remaining in a sprint, day-by-day.
  • Sprint Backlog – a subset of features to be worked on/implemented in the next sprint.

The three ceremonies are:

  • Spring planning – a meeting to determine how many of the features from the product backlog to implement in the coming sprint and translate those features into specific tasks.
  • Daily Scrum – a daily 15-minuted stand-up meeting where each member of the team answers 3 questions; what did you do yesterday, what will you do today and are there any obstacles. Thus everyone on the team is on the same page, knows what is going on and problems/obstacles can be surfaced early.
  • Sprint review – two part meeting where the first part is a demonstration of the shippable product/code developed in the last sprint and second part is a retrospective where the team works with the ScrumMaster to assess the way they worked together and identifies positive ways they worked together and strategies for improvement.

Any project consist of several steps.

Step 1. Project Vision, Business Goals, Project Constraints and Definition of Done.
Project Vision:
Why are we doing this project. Why are we developing this service. What is the purpose. This is the one-liner describing the purpose of the project – the why.

Business Goals:
What is it going to do. A prioritized list of what business goals we have for the project, measurable. For example increase sales of product x.

Project Constraints:
What are the constraints in this project. It could be time, we have a firm deadline to meet. It could be cost, we have a firm budget to adhere to. We can only spend so much. Or it could be scope, we can only do this many features.

Definition of Done:
When do we know when we are done with a sprint. It is important to have a clear definition of done before the project starts so we can measure our progress against it to know if we have accomplished what we said we would.

Step 2. User Stories/Project Backlog
What should our product or service be able to do. Basically what features do we need in our product or service. This should be driven by user needs so we make sure we build products and services that customers/users actually want to use. To do this we can create user stories. They take the form of:

As a <user> I would like to <action>, so that <value>

For example if we are building/developing a tablet computer we might have a user story like this:

As a hobby photographer I would like to easily transfer my photos to the tablet so that I can edit, organize and share them on the fly.

It will then be up to the team to figure out how to implement this feature.

As you can see we replaced the <user> with hobby photographer. When creating user stories we must be specific about who the user is, not just call them users. To figure out who our users are we can create personas.

Step 3. Sprint Planning
In the sprint planning the team decides how many of the features/items from the product backlog they have capacity to complete in the next sprint and add those to the sprint backlog. The team then goes on to break the sprint backlog into tasks.

Step 4. Sprint
The team works on the tasks defined in the sprint planning. There is a the daily scrum meeting where any obstacles are raised and everyone communicates about their work to ensure the team is on the same page.

Step 5. Sprint Review
As mentioned above this is where features that are done (according to the definition of done) is previewed to stakeholders, users, and others. And where the team does a retrospective to see what worked, what isn’t working and what adjustments should be made to improve performance for the next sprint.

After this celebrate the success. Then go back to Step 3 and start over with a new sprint. Figure out what features to work on, break them into tasks, implement any process improvements, go through the sprint, do another sprint review. Iterate through until the product (version) is complete.

Hopefully this brief overview gave you a better understanding of Scrum and how it is applied to software development. In the next parts of this blog-post series we will see how we can take elements from this Scrum framework and apply those same principles and steps to presentation design.  Stay tuned for Part 2.

This was a very simple overview of Scrum and if you would like to learn more about Scrum here a few good starting points.
Scrum Allicance
Scrum on Wikipedia

3 thoughts on “Scrum and Presentation Design – Part 1: Introduction to Scrum”

Leave a Reply

Your email address will not be published. Required fields are marked *