This article is part of our project management methodology series.

In our previous articles from the agile series, we tried to demystify the concept behind the Agile approach to project management, tackling its values and principles speaking both in theory and experience.

Also, we reflected on our own experience in getting the most out of agile, by pointing out the main benefits coming from the approach itself.

This time, we are through with the theory, let’s get our hands dirty.

The most commonly used framework for implementing the Agile project management methodology (especially in the software industry) is called Scrum.

A bit of history

Back in the day, Scrum was first defined as “a flexible product development strategy where a development team works as a unit to reach a common goal” – quite different from the more rigid, sequential traditional strategy.

The origins of this approach were found in the New Product Development Game by Hirotaka Takeuchi and Ikujiro Nonaka.

They called this the holistic or rugby approach, as the whole process is performed by one cross-functional team across multiple overlapping phases, where the team “tries to go the distance as a unit, passing the ball back and forth”.

Inspired by their work, Ken Schwaber and Dr. Jeff Sutherland formalized Scrum into the framework as we know it today.

How does it work?

Scrum is a simple, yet powerful agile framework for managing projects in new,complex, changing environments. It is the most popular framework used across different industries, but it is still most commonly used in software development projects.

The idea behind Scrum development is to focus on small iterations, thus incrementally building the product. This allows you to work on small portions of work while continually getting customer feedback.

The whole process is driven by the Scrum Team. This team is formed around specified roles, working through cyclical events and artifacts associated to them.

Scrum relies big time on“Inspect and Adapt”, helping the Team get better as they go. Starting with the premise that learning, change and innovation is an inevitable part of the process, Scrum emphasizes the following:

• take small increments of work during development,
• inspect the results of both the working product and the efficacy of current practices,
• learn and adapt product goals and process practices,
• repeat forever.

Where do you start?

The story of the pig and the chicken.

This story is often misinterpreted or used out of context, and in some cases even seen as offensive…yet, this is just a cartoon and the bottom line is that it explains how people are organized during a Scrum project.

It basically plays a distinction between those who are committed by being directly responsible for the production and delivery of the final product (the product owner, development team, Scrum master).

On the other hand you have those who are involved, but don’t take an active or direct part in the production and delivery processes. However, involved members are still very important stakeholders (customers, other departments, managers).

Product Owner

This person is practically behind the wheel, keeping everyone going in the right direction.

The product Owner is responsible for defining what the right product is. His main role is to define the Product features and prioritize them.

This way he decides which items will be worked on in the next development cycle. The Product Owner continually re-prioritizes and refines the product items. He also actively and frequently interacts with the Team, personally offering the priorities and reviewing the results.

Development team

The development team is a cross-functional group of self organized individuals who work on building the actual product.

The Team pitches their ideas on how to make the best product possible by interacting with the Product Owner. When they start working on product priorities, The Team decides what to commit to, and how best to reach these goals.

Jeff Bezos had something good to say about the optimal Scrum team size: “If you can’t feed a team with two pizzas, it’s too large”.

Keeping the team small enough to remain agile and large enough to handle any amount of work within an iteration, is the sweet spot – in our opinion, that’s 5 people per team.

Scrum Master

The Scrum Master keeps everyone on the same page. He is somewhat of a bridge between the Product Owner and the Team.

Unlike the traditional manager, the Scrum Master facilitates the whole process by serving the team as it organizes and manages itself. He supports the Scrum Team, coaching and guiding them through this process, and removing any impediments blocking their progress.

This person provides the team with everything they need to get the job done, at the same time making sure that everyone understands and follows the practices of Scrum.

You win with people, remember?

Before you jump into Scrum, you should be able to form a team of 100% dedicated individuals, willing to embrace Scrum practices, and ready to devote a reasonable amount of time to support their team’s success.

Successful Scrum usage depends on this, but more importantly, this is how you help your team thrive and grow.

So, get everyone on the board and you are ready to kick off.

Step #1 Defining Product Backlog

In order to build something, you need to understand the general purpose of the product. What problem are you trying to solve? The Product Owner is the first person who should know this. He has the product vision that will eventually evolve into a refined list of features – the Product Backlog.

Simply put, the Product Backlog is a prioritized to-do list, containing short descriptions of functionalities. The Product Backlog should evolve over the lifetime of the product, something like a production roadmap.

So let’s see what goes into The Product Backlog:

User stories

These are main the features we want to implement. A user story is a short, one sentence definition of a feature or functionality. It is referred to as a user story, because it is presented from the perspective of the product’s end user.

Now, the User Story only describes a feature, it doesn’t say how to implement it. It should only describe the behavior or flow from the user’s perspective.

What does your user want to do?

As a <type of user>, I want <to perform some task> so that I can <achieve some goal/benefit/value>

As a business user I want to be able to set a due date for my task, to make sure that the tasks are done on time.

Bugs

Because there’s really no difference between a bug and a new feature (we’re talking from user perspective, remember?), bugs are also put on the Scrum product backlog (we have a better idea on how to solve this, but that’s a story for another article).

When a user adds an email as a task in Split View, 2 tasks are created instead of one.

Technical work

Technical work is not directly related to the user’s actions, rather it’s work done under the hood.

Run database script to move all events from old to the new calendar.

Knowledge acquisition

Due to the level of uncertainty in work items you will need to buy essential information.

Research how Gmail is doing its syncing mechanism on Android.

As you can see, items on the Product Backlog should be expressed in business terms which are clear to the user, and not as technical tasks.

If you can’t explain it simply, you don’t understand it well enough. – Albert Einstein

Items that need to be done in upcoming Sprints should be small and clearly defined, standing as separate, distinct pieces of work.

Anyone can add anything to the Product Backlog, but only the Product Owner can prioritize it. He is expected to continually update priorities to reflect changes in customer needs, new ideas, technical pitfalls etc.

Prioritization

What direction is your business heading currently? What are you up to with this product? Which 20% of your features are your customers using 80% of the time? When are these features due?

The Product Owner prioritizes the backlog using answers to such questions, making sure that all stakeholders get maximum value in the shortest possible time.

Priority of the user stories is simply defined by the order of the Product Backlog list.

Estimation, a question of relativity

You are looking at the Backlog items, and you are still not sure how they will actually work, or which steps you need to do take to make that happen. How are you supposed to start making the product without having the gist of how much work lies ahead?

At this moment, you need a really solid estimate in order to get a prevalent understanding of how to get around potential hurdles. Eventually your Team will be able to refine the estimates as they go – simply by learning by doing.

Dealing with the complexity of production systems is not easy, and your Team will be able to give guesstimates, rather than precise timeframes backed with heavy details.

You don’t want to spend too much time estimating because estimates alone don’t bring any value. They are expected to change over time, and the only thing that counts is the work you deliver.

We make estimates for:

• the product backlog to be fully prioritized based on relative item cost
• knowing what can be done and when, based on high-level projections
• making compromises between scope and schedule

A common practice in Scrum is to estimate your product backlog in points, rather than timeframes, in order to describe the effort. There are several techniques for this:

The Fibonacci sequence

A set of numbers, where each number is the sum of the previous two. They are:
1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610…

Looking at this range, 1 could be a simple fix in UI, while 610 could speak for the effort of, let’s say…growing potatoes on the Planet Mars! But you don’t want to burden your Team with fancy estimation skills, just play it simple. A range from 1 to 21 will do the trick.

Relativity is the key (gravitational waves are recorded, so this is a fact now).

At the beginning of the process, the team looks for the smallest story on the backlog and gives it a 1 point. Then they decide on the biggest story on the backlog, giving it a 21. When you set these as reference stories, you can decide on the priority level of others, in relativity to the 1 and 21 stories.

What if someone saw issues that others didn’t? Or someone might have thought of a better/simpler approach? There is always room for a second opinion. Discussing as a Team can help everyone set better estimates.

The Scrum Master is welcome to encourage conversation around the items in order to reach a shared understanding, and to make sure everybody is equally engaged.

Alright then, we have a product backlog ready, what shall we do next?

Step #2 Sprint Planning

Scrum is cyclic, it thrives in healthy, consistent routines.

Scrum is made up of several development cycles, Sprints. A successful Sprint Planning meeting first settles on the Sprint duration as a team. It is best to set timeboxes for each Sprint, no longer than a month.

The duration of a Sprint depends on a lot of things, most of all how experienced your Team is with Scrum. Experienced Teams can commit to shorter Sprint cycles.

However, a shorter Sprint is not necessarily a more successful one, consistency is key here. Consistency makes a good foundation for forming routines, routines are healthy for flawless teamwork. A team that plays together knows how many Product Backlog points they can do together.

You should have two things settled after a sprint planning meeting – a Sprint Goal and a Sprint Backlog.

The Sprint Goal is decided on by the Team and Product Owner, just one or two sentences on what you want out of this Sprint. The Sprint Backlog lists out all the product backlog items to be delivered in this Sprint, as well as what needs to be done to deliver them.

Part 1 of the Sprint Planning Meeting

The Product Owner and Team go through the Product Backlog to select items to work on this Sprint. The Product Owner explains goals and context behind these high priority items to the Team. The Team gathers all the information they need for a User Story to become a detailed item in the Sprint Backlog. The Scrum Master oversees this.

Part 2 of the Sprint Planning Meeting

The Sprint Planning Meeting becomes a Sprint Planning Workshop, where tasks are defined and time estimates for their completion are made.

The Team can now discuss requirements and features with the Product Owner, and impart their own technical know-how on them. They can fine-tune their original estimates. It is very important that the Team has a say in which items from the Backlog should be worked on, because they are the ones committing to them in each Sprint.

How to keep everyone on track?

In order to foster collaboration throughout the project, it is important to keep the work structured and visualized, so that everyone in the Team can keep an eye on the progress while continually updating the work left to do. Ideally, put everyone on the planning board. This is how Yanado does it:

• Product Backlog – list of prioritized user stories representing all product features
• Sprint Backlog – list of user stories Team will work on in the next sprint based on the priority
• Open – tasks related to user stories from the Sprint backlog that need to be done
• Doing – tasks actually being worked on by the Team
• Dev (optional) – tasks that are done by the team but not yet sent for testing
• Stage – tasks sent for testing
• Done – completed and tested tasks ready for production deployment

Step #3 Sprint

Once a Sprint starts, the Team calls the shots. Should a manager come into the decision making process, the Team loses control and commitment, bit by bit.

A manager should instead focus on supporting the team, not instructing them. If need be, the decision making process can be facilitated, which is consequently a crucial skill of any agile manager. The Scrum Master practices servant leadership.

Within a Sprint, the Team should focus on delivering what they’ve committed to deliver. Changes at this point could greatly slow down productivity, and in the worst case scenario, they can miss the Sprint timebox.

The best way to stick to your timebox is to work feature by feature. Multitasking will give you 90% of a few features, which means they are undeliverable. You need to deliver 100% of something.

Daily StandUp Meeting

The Team uses Daily Scrums to keep up with, self-organize, and commit to each other.

Include 15 minute meetings every day, where the whole Team synchronizes their daily duties, and reports any obstacles. These are the questions everybody should go over:

• What did I do yesterday?
• What will I do today?
• Did I come across any obstacles?

This Daily Scrum is not a meeting where the Team reports to the manager. It is an opportunity for a self-organizing Team to coordinate, and the Scrum Master merely facilitates Daily Scrums – keep them short and sweet. He also deals with obstacles – usually by delegating them. It is their obligation to tackle all obstacles, and fast.

Measuring the progress/Updating Burndown Chart

“The problem with Scrum team finishing within a timeboxed Sprint is similar to trying to land an aircraft on a runaway. -Jeff Sutherland

The Team is supposed to update the Sprint Backlog whenever they make new progress – once a day, often more. This can be done during the Daily Scrum. The Scrum Master compiles all remaining tasks in the Sprint into a Sprint burndown chart.

The Sprint Burndown Chart shows the Team’s progress, and how much is still left to do. The Sprint is detailed on the horizontal axis, the remaining amount of work (in story points, time, or something similar) at the start of each Sprint is detailed on the vertical axis.

This progress is measured so that Product Managers can set precise estimates for future Sprints. Over time, the Team sets more precise estimates for the items they can commit to as well. With more precise estimates, you build consistency. You can extract the Velocity of the Team’s progress with this data.

The Sprint Burndown Chart is as useful as the consistency with which the Team updates their story points and time estimates.

When a Team manipulates their progress updates in order to make their Chart look good, they did more harm than good, naturally. The Chart needs honest results, because its purpose is to show progress and evaluate possibilities for future Sprints. Polished results will set expectations too high, and the Team might find themselves in a pickle.

Step #4 Sprint Review

There are three reasons for Sprint Reviews:

• The Team can demonstrate their achievements and contributions.
• The Team can focus on Sprint Timeboxes – everybody has to bring something to the Review table!
• Key Stakeholders monitor progress and regularly provide feedback, while there is still time for changes.

The Agile Team has to deliver some form of minimum viable product at the end of each Sprint. That means, at the end of each cycle, you have a coded, tested, and functional piece of software.

Sprint Review Meetings come at the end of each Sprint, naturally. This is where the Team demonstrates their accomplishments, which often means that they present new completed features. The meeting is brief and informal – no slideshows, no lengthy preparations… There isn’t too much pomp around these meetings, they are the natural end of a development cycle, a Sprint.

Sprint Review Meetings are attended by the Product Owner, the Scrum Team, the Scrum Master, management, customers, and any other stakeholders. The final product is compared to the Sprint goal that has been decided on the Sprint Planning Meeting. Ideally, all the Backlog items should be completed, but reaching overall Sprint goals is higher on the priority scale.

Step #5 Sprint Retrospective

The knowledge you have earned in the past Sprint can be used to make the next Sprint better.

Scrum Agile development is a continuous learning process. Product and knowledge is achieved in small but regular increments. This allows for early feedback, which allows for easier changes, should they be necessary (and they always are).

The Scrum Team understands that there is always room for improvement, and they reflect on these possibilities at the end of each Sprint.

The Sprint Retrospective is where the Team evaluates processes and progress, in order to improve them in time for the next Sprint:

• How did the Burndown Chart fare? Did the Team deliver everything they committed to?
• How was the Team Velocity? How many Backlog items were completed in the Sprint? Velocity is best displayed on a graph where the Team can see whether they are working up to par at any moment. Once a pattern shows in the Velocity, it can be used to plan future Sprints as a realistic estimate.
• What were some of the bigger successes in this Sprint, and how can you repeat them?
• What was not a success, and how can you make it a success in the next Sprint?
• What will you change in the next Sprint? It is best to provide actual practical examples that can be implemented in the beginning of the Sprint.

The next Sprint

The Team should leave the completed Sprint all the wiser, with more information about the product, their personal performances, and how to make obstacles not happen this time around.

Practice has shown that a team will find their pace in the 3rd or 4th Sprint. This is when Velocity becomes a pattern that can be used for future estimates, when most obstacles have been removed, and working processes are perfected. This is when your Team starts looking like an Experienced Scrum Team.

…

Well, this was one long post, isn’t it.

If you have any questions or you don’t agree about anything let us know in the comments.

Oh one more thing, feel free to share it and let the world knows about it!