alice cooper - art of scrum

The art of Scrum – review by Food Tuner

Help us! Share this article :-)Share on FacebookPin on PinterestTweet about this on TwitterPrint this page

All rock stars a.k.a. entrepreneurs should learn the art of Scrum. In principle, everything seems logic, but can be a bit confusing when you start using tools like JIRA.

Here is some advice to help you to set your backlog and your scrum meetings right.

The Band

First of all, in a scrum team, you have different roles:

The product owner

He’s the guy or the women with the vision. He’s always talking with the customers / users. He makes priorities for the team. He’s the final arbiter of requirements questions. He focuses more on the what than on the how.

The scrum master

This person has no management authority, he’s a facilitator. As a consequence, if you are the project manager or the line manager of the team, by definition, you cannot be the scrum master.

The scrum development team

This team is composed of people from various functions in the startup. They are back-end, front-end developers, designers, system administrators, testers etc. Their aim is to build a “potentially shippable product increment” every sprint. The members are team players, they work together, help each others and learn from their work.

 

 So if you are a very small team, make sure your roles are clear from the beginning. Who’s the product owner? Who’s the scrum master?

 

The product Backlog

 

The product backlog is a list of items  all the features and actions your product might ever do. Be careful, here we are talking about the Product, not the startup. Therefore “launch a crowdfunding campaign” is not a Product Backlog Item (PBI).

This product Backlog is sorted by priority: the most import item on top.

It’s the Product Owner who expresses his requirements to the team. Here is an example “our users are requesting the recipe steps, which is more important than to be able to save some favorite recipes”.

 

The Sprint Backlog

 

In a startup, things go fast. In fact, you need to make short releases in order to test what you have developed with your users. The earliest you notice you are on the wrong path, the better.

As a consequence, the standard sprint format tends to be 2 weeks, but you can make go up to one month.

For the current sprint, the team agrees on the Product Backlog Items they want to work on.

In tools like JIRA, you can create PBIs using stories and then, you define how to develop these PBIs by creating tasks. Afterwards, you will move these task on your scrum board from Not Started (or To Do) to In Progress and then Completed (or Done). You can also add a “In testing” column.

Be careful to size your BPIs well, see Product Backlog refinement meeting.

 

The product backlog refinement meeting

This meeting is very important. Dedicate regularly 2 hours to go through the product backlog. You probably won’t have time to talk about all the items, but the most important is to tackle the top of the list.

The aim of this meeting is to make sure the BPIs are fulfilling the following criteria:
Independent
Negotiable
Valuable
Estimable
Small
Testable

 

One solution is to use cards where it’s written Small Medium Large and Extra Large (or S, M, L, XL). Select the top item on the backlog. Each member must choose a card. Each member must afterwards explain why they picked their card, in particular if they are different. Making this exercice, you will realize that your PBI is probably not fulfilling the criteria above. As a consequence, work together to size it down to smaller items or user stories.

If you figure out for example that they are several users stories inside your PBI, then you can probably turn this PBI into an epic with several user stories.

Go through the card process again until every one picks up the same card.

Then review the prioritization you have made.

Don’t forget to define acceptance criteria for every PBI. This means, how will you measure if you can consider this user story as completed or not? For instance: feature working on Chrome on computers and mobile (see Sprint Planning Meeting for more information)

 

Sprint Planning Meeting

 

The decisions for the sprint are very important, so really take time to review the items. Dedicate 4 hours for a 2-week Sprint.

Your sprint should contain these steps if you are aiming to release a user story: analysis, design, implementation, testing, integration and deployment.

The product owner will share his priority list with the team. Together, they must review if they can commit to it within the sprint time.

Set up completion criteria. A task is done when it’s:

properly tested
refactored
potentially shippable

 

Questions to be asked at the end of the meeting:

1. What are the tasks to be made to get these stories into a potentially shippable state?

2. Do you think we can do this in two weeks without compromising our definition of “done” and without working overtime?

3. Anybody thinks we can’t do it?

The team is now committed to complete this PBI within the sprint. You can now pass to the second BPI and do the same work.

Question:

4. Can we make both of these BPIs within 2 weeks?

5. Anybody thinks we can’t do it?

The team is now committed to complete this PBI within the sprint. You can now pass to the third BPI and do the same work.

At the end of the meeting, you can decide on who’s is doing what or wait for the sprint to begin.

Daily Scrum Meeting

 

Duration: 15 minutes.

Each participant must answer these 3 questions:

1.What did I do yesterday (or since the last Scrum meeting)?

2.What will I do today (or before the next Scrum meeting)?

3. What blocks my progress or reduces my effectiveness?

At this point, when you’re reviewing what needs to be done, you can update your project in JIRA or on your physical scrum board where you pick up a task and nominate someone.

If there are topics you need to talk offline, write them down and review them later.

 

Sprint Review Meeting

 

You can invite external people to your Sprint Review Meeting. These can be people from sales, for example. The highlight of this Sprint Review Meeting is a live product demonstration.

The product owner will assess which of the PBIs committed to the Sprint meet the acceptance criteria agreed at the Sprint Planning Meeting and whether Sprint goals are met.

Agenda:

1. Product Demonstration

2. Product Owner declares what’s done

3. Measure velocity

4. Stakeholder feedback

If additional features are requested by the product owner, they can be added to the Product Backlog and integrated to the next Sprint.

 

I hope this clarifies a little bit, do not hesitate to leave us comments!

Cheers!

Food Tuner

Food Tuner gives you ideas of recipes from ingredients. So you can buy fresh food and new product without planning your recipes in advance.

Help us! Share this article :-)Share on FacebookPin on PinterestTweet about this on TwitterPrint this page

Anne-Sophie

French from Brittany, I'm an explorer. I'm always learning and solving problems.