Here’s a good video guide on Scrum

Planning a new sprint

Scrum starts with sprint planning. Your team defines sprint duration and then work to be done. These are two central questions for a planning meeting.

1. What should be done in this Sprint?

Scrum team is lucky to choose the amount of work for the Sprint. It’s not like “deliver that feature asap”, but — “we can deliver that much in two weeks”.

As a Product Owner you define the direction and focus, and let the team decide on the work they can get done in a chosen direction during the Sprint.

2. What is the Sprint’s Goal?

Next, the team should agree on the Sprint’s goal. Yes, it’s essential. It aligns team members and the Product Owner on a shared mission for the iteration.

Without an upper-level task (‘goal’) a team can fall into working on separate tasks that don’t lead to significant product improvements.

Goals show a broader view of the team’s plans and what should be presented at a Demo meeting.

Tips for planning a new sprint

sprints duration should be the same to keep working rhythm;

try not to change a Sprint goal (if the goal has changed it’s better to wrap up the current sprint and start a new one);

more advice is provided here;

Running standup meetings

Standup meetings are about focus, accountability, and motivation. They keep the team on the same page on a personal and business levels.

A daily short meeting helps to keep the whole team focused on the sprint goals showing who’s doing what. For remote teams, it also serves as a way to connect on a personal level with the whole team.

Some developers hate standups but don’t worry, you can make it right. Here is the way they’ll like it.

1. Pick a schedule that works for everyone on your team.

2. Explain to your team why you’re doing it.

3. During a meeting ask everyone three simple questions:

- what did you accomplish yesterday?

- what do you plan on doing today?

- do you have any obstacles?

4. Don’t let a meeting last longer than 15 minutes — be short and concise.

Remember, your goal is not to ask each person to report their status. Instead, team members should talk about how team goals are progressing.

Celebrate small victories by telling them “good job” after a task is completed. As a result, your team should feel more motivated after a standup meeting.

Tips on running standup meetings

don’t skip a meeting if someone can’t attend; it’s better to have it with the half of your team than don’t have it altogether;

if your team is remote or has flexible schedules try running asynchronous standups via Slack;

Today many teams are embracing the new way of doing stand-up meetings asynchronously. They use stand-up bots in Slack to gather and share team updates without the need for everyone to be on the call.

Not using Slack? Get started with $100 off by using a special discount from our team at try.slack.com/standuply 💸

Running retrospectives

A retrospective is a meeting held at the end of a Sprint to discuss what was done right and what can be improved.

Many teams skip it. Don’t be like them — it’s like skipping a health check.

To run a good retro, you need to decide who’s the host and then gather the whole team including product owners. Spend ~ 30 minutes on that.

Step #1 — Gather opinions and count votes

Gather items the team liked and disliked about the past Sprint. Do not discuss them yet, just make sure to write all them down on a whiteboard.

Then run simple voting to define most popular issues for a discussion. Remember, your task is to continue doing what works and get rid of the rest.

Step #2 — Discussion.

Discuss the main issues now and find the ways to resolve them. It may take time to find right solutions, formulate and assign tasks.

The whole team should decide what they want to:

start doing in the next Sprint;

stop doing;

continue doing;

In the very end of the retro, you can quickly discuss results from the previous ones. Sometimes the correction of the past tasks takes place as well.

Step #3 — Meeting notes.

Fix the results of the retrospective meeting in meeting minutes or in a task tracker adding relevant tasks. Then share the results with all participants.

Tips on running retrospective meetings

a team leader shouldn’t be a host — usually, it’s Scrum Master’s role;

Counting story points

Few people count story points consistently. But if you invest in that process then over time it will pay off significantly.

Counting story points is a key to measuring team’s productivity.

It’s a comparative metrics. You compare tasks to one another. Like this — “I brought a pizza twice larger than yesterday, it will then feed 2x more people”.

Choose a previously completed task which is well known to everybody. Name it as the one story point and compare all upcoming tasks with it.

If you don’t have any completed task (e.g., starting a new project), choose any task which is clear how to accomplish to all your team members.

Here’s how it works.

Have a physical/online board with numbers 0–0,5–1–2–3–5–8–13–20–20–40–100. Put a card (or a tag) of a story point in a “1” column. Every new task should be placed in a corresponding column compared to the story point. Choose a larger number if it’s not in the list of numbers. Don’t worry too much about being super precise —you’ll get it later. Once you’ve done with all Sprint tasks — you have the total number.

Sounds easy, but the most complicated part is doing that on a regular basis. Three simple practices below will help you.

always evaluate the stories team puts on the sprint/product backlog;

evaluate the stories team puts on the sprint/product backlog; during the sprint track completed story points to assess the progress;

to assess the progress; use the total number of finished story points in previous sprints to plan the next iterations considering the productivity of the team;

Tips on counting story points

don’t use numbers larger than 13 or 20; leave it for tasks larger than your average Sprint;

don’t consider there is work with zero effort; even the smallest request takes some time — use a 0.5 value for this;

use sizes like for a t-shirt, small — 2 story points; medium — 4; large — 8. With each new sprint your assessment will become more refined;

see more advice here and here;

Tracking Scrum Metrics

If you’re a fan of measuring everything, it’s the part for you. If you’re not, but still reading — maybe it’s time to become the one.

Scrum provides a team with a set of metrics to track and improve team productivity. Let me tell you about the most effective ways to do so.

Burndown chart

The main Scrum metrics allowing you to track completed work and predict the sprint results is the Burndown Chart. You put the number of unfinished story points on the Y-axis and days of the Sprint on the X-axis.

If a team adds more tasks during the sprint, then burndown may go up. Ideally, on the last day, you should reach zero.

Percentage of finished story points

It’s an effective way of measuring progress. You should calculate both the number of completed story points and its percentage.

It helps the team to focus on performing the functionality but not on the tasks. Besides that, this it helps the development of cross-functionality in the team.

BurnUp Chart

This chart shows when all the planned tasks will be completed. It consists of two lines — the one with total tasks, another with finished tasks.

On the X-axis you place dates, on on the Y-axis you put the number of story points accountable for your tasks.

Red line — work to be done; blue line — work done

The main use-case for a burnup chart is tracking Releases that consist of several iterations. This way you can be sure you’ll meet the deadline.

Team Velocity

Once you finished several sprints you can track the Velocity of your team. This is where counting story points pay off (you can’t do the same with hours).

On the X-axis, you put Sprints, on the Y-axis you put corresponding story points: planned/completed using bar charts in different colors.

This way, you can view past results and plan future volumes of work.