software development with...

Software Development with Scrum

Andrea Polini

Software Project ManagementMSc in Computer Science

University of Camerino

A.Y. 2017/2018

Andrea Polini Software Development with Scrum SPM – A.Y. 2017/2018 1 / 41

Introduction

What is Scrum?

Scrumis an Agile methodology – i.e. a collection of practices combined withideas, advice, experience (BoK) – to software system development

certainly the most adopted agile methodology

Introduction

Which are the most important characteristics?

Scrum embodies the following practices:Three main roles in Scrum: Product Owner – PO, Scrum Master –SM, Team Member – TMThe product owner creates and mantains a product backlogThe team runs timeboxed month-long sprints. The requirementsfor the current sprint are called the sprint backlogThe team meets for a daily standup meeting in which everyonetalks through the work they did the day before, the work they planto do today, and any obstacles in their waythe Scrum master keeps the project rolling by working with theteam to get past “roadblocks”. He/she drives the sprint review andthe retrospective

Better-than-not-doing-it

It is possible to adopt all of these practices still missing to become anAgile team

Introduction

Scrum basic rules – Sprint planning

1 Attendance: SM, PO, TMs2 Meeting divided in two different parts, each one lasting 4 hours –

Exploration and Operative plan – duration can be reducedaccording to the duration of the sprint

3 PO comes with an already prioritized backlog4 1st part of the meeting: PO and TMs works together to select

items to be delivered during the next sprint. The sprint backlog isformed.

5 2nd part of the meeting: TMs, with the help of the PO, figure outthe individual tasks needed to implement the selected items.

Introduction

Scrum basic rules – Daily scrum

1 Attendance: PO, SM, TMs2 Period: every day3 Duration: 15 minutes (timeboxed) – everyone should be on time!4 Characteristics: stand-up meeting5 Objective:

What have I done since the last daily scrum?What will I do between now and the next daily scrum?What obstacles and roadblocks are in my way?

6 Follow-up meeting among interested members to further elaborateon possible emerged issues

Introduction

Building the team

If you are asked to organize the team for the next project, and youwould like to give a try to SCRUM, consider that:

People do not come on board if they are not convinced. In teamsaccustomed to WF like processes people can be reluctant toaccept the challengeYou need support by the managementTry hard and be persuasive

Introduction

Consultants vs. Team members

Team members are generally multitalented and have variegatedinterestsConsultants are generally much more specialised and they areconsidered gurus in their specific competenceTeam member are full tim onth eprojectConsultants are enrolled when needed and they can enter theproject for a single sprint. When involved they are peer withrespect to team members

To build the team list the competences and skills you need on the rowsof a table. Add a column for each potential team candidate rating eachquality with a mark within 1 and 5. Cover all the skill and competencesyou need with team members and consultants trying to get themaximum sum. Teams generally include within 5 and 9 people

Introduction

Scrum basic rules – Sprints

1 Duration: typically within 2 and 4 weeks, or a month.2 Characteristics: timeboxed3 How to: as soon as a TM recognizes he/she has overcommitted

report to PO, that then will have to inform the users/stakeholder4 Product backlog should be visible to everyone. Generally sprints

cannot be stopped (in case the PO)

Introduction

Scrum basic rules – Sprint closing

1 The software is presented to the stakeholders (only the runningpart of the system, no diagrams are admitted)

2 stakeholders are asked to provide their opinions and feedbacks.The PO possibly update the PB.

Introduction

Scrum basic rules – After the sprint

1 Retrospective meeting is held. Each one answers to the followingquestions:

What went well?What can improve in the future?

2 SM takes notes and possibly adds items to the PB for nonfuntional items

Introduction

Roles – Scrum Master

The SM is not the traditional PM in a command-and-control project.The SM does not own and mantain the plan. Guiding the team is hismain responsibility. The SM:

drives the team in the adoption and usage of scrum practicesprotects the team from “unfair” requests from the POhelps TMs to feel owenership for the project

Introduction

Roles – Product Owner

The PO is the one who made the commitment to the companyThe PO is generally acquainted with the business domain of theprojectshould get the TMs able to understand the goals of the project, sothat they can commit to the project itselfs/he meets everyday with the TMs and takes day-to-day decisionsto drive the project, possibly changing the backlogThe PO manages the PB prioritizing the items in itbrings the view of users and stakeholders in the project.

CommitmentPromise made by people to gets certain things done, usaully by acertain time

Introduction

Commitment vs. involvment

A Pig and a Chicken are walking down the road

The Chicken says: Hey Pig, I was thinking we should open arestaurant!Pig replies: Hm, maybe; what would we call it?The Chicken responds: How about ’ham-n-eggs’?The Pig thinks for a moment and says: No, thanks. I’d be committed,but you’d only be involved!

Commitment refers to each role and should be fostered by each other

Introduction

Commitment vs. involvment

A Pig and a Chicken are walking down the road

The Chicken says: Hey Pig, I was thinking we should open arestaurant!Pig replies: Hm, maybe; what would we call it?The Chicken responds: How about ’ham-n-eggs’?The Pig thinks for a moment and says: No, thanks. I’d be committed,but you’d only be involved!

Commitment refers to each role and should be fostered by each other

Introduction

Scrum values

Every company has a culture (e.g. separation of duties, transparency).When the culture mathches agile values and principles the adoption ofagile methodologies will be much more successful. Scrum has its ownvalues:

CourageCommitmentRespectFocusOpeness

Introduction

Courage

Team members have the courage to stand up for the project . . . Scrumteams have the courage to live by values and principles that benefit theproject. It takes courage to ward off the constant pushback from acompany whose values clash with the Scrum and agile values.

Introduction

Courage

Team members have the courage to stand up for the project . . . Scrumteams have the courage to live by values and principles that benefit theproject. It takes courage to ward off the constant pushback from acompany whose values clash with the Scrum and agile values.

Introduction

Commitment

Each person is committed to the project’s goals. . . team has theauthority to make decisions in order to meet project’ goals, andeveryone can influence how the project is planned and executed

Introduction

Commitment

Each person is committed to the project’s goals. . . team has theauthority to make decisions in order to meet project’ goals, andeveryone can influence how the project is planned and executed

Introduction

Respect

Team members respect each other . . . then they trust each other to doa good job with the work they’ve taken on.The SM should find ways to increase mutual respect in the team.

Introduction

Respect

Team members respect each other . . . then they trust each other to doa good job with the work they’ve taken on.The SM should find ways to increase mutual respect in the team.

Introduction

Focused

Everyone is focused on the work . . . a TM working on a sprint shouldnot be distracted by other activities for the duration of the sprint (fulltime assignment). Switching people among activities lead to waste oftime and money

Not attending a formative activity does not put in danger the career ofthe TM

Introduction

Focused

Everyone is focused on the work . . . a TM working on a sprint shouldnot be distracted by other activities for the duration of the sprint (fulltime assignment). Switching people among activities lead to waste oftime and money

Not attending a formative activity does not put in danger the career ofthe TM

Introduction

Openess

The teams value openness. . . when you’re working on a Scrum team,everyone else on the team should always be aware of what you’reworking on and how it moves the project toward its current goals.

In many company you can observe a culture discouragingtransparency. Rigid hierarchy that depends on opaqueness

Introduction

Openess

The teams value openness. . . when you’re working on a Scrum team,everyone else on the team should always be aware of what you’reworking on and how it moves the project toward its current goals.

In many company you can observe a culture discouragingtransparency. Rigid hierarchy that depends on opaqueness

Introduction

Daily Scrum

The Daily ScrumIt functions as an inspection of the work that the team is doing, so TMscan adapt that work to deliver the most value. And it gives the team theopportunity to make decisions at the last responsible moment, givingthe flexibility to have the right person do the right work at the right time

Team moodinterested - listen to colleagues statementscollaborative - if you can help do ithumble - people generally make mistakes

Introduction

Daily Scrum

The Daily ScrumIt functions as an inspection of the work that the team is doing, so TMscan adapt that work to deliver the most value. And it gives the team theopportunity to make decisions at the last responsible moment, givingthe flexibility to have the right person do the right work at the right time

Team moodinterested - listen to colleagues statementscollaborative - if you can help do ithumble - people generally make mistakes

Introduction

Daily Scrum – How to

How to hold an effective Daily ScrumAct like a “pig” – do not ignore the “to do” columnTake detailed conversation off-lineTake turns going firstDon’t treat like a ritualEveryone participatesDon’t treat it like a status meetingInspect every taskChange the plan if it needs to be changed

Introduction

Sprints and Planning

Scrum is based on:Iterative and Incremental approach to software developmentEffective project planningFrequent delivery of running software (value to customer)User needs defined in User stories

Introduction

User Stories

What is it?A simple and quick description of a specific way that the user will usethe software. Generally between one and four sentences long stays ina 3×5 index card

They permit to deliver value to the customerReduce the risk of gold-plating

Can generally follow a template:

As a <type of user>, I want to <specific action I’m taking> so that<what I want to happen as a result>

Introduction

User Stories

What is it?A simple and quick description of a specific way that the user will usethe software. Generally between one and four sentences long stays ina 3×5 index card

They permit to deliver value to the customerReduce the risk of gold-plating

Can generally follow a template:

As a <type of user>, I want to <specific action I’m taking> so that<what I want to happen as a result>

Introduction

User stories and satisfaction conditions

Introduction

User stories and satisfaction conditions

Introduction

Story points

Useful tool to assess the effort needed to elaborate a user story.The objective is to assign a value to each user story using acomparative analysis

1 value each story between 1 and 5 (or 10)2 Or use Fibonacci numbers (f0 = 1, f1 = 1, fn = fn−1 + fn−2)

How?discussion among team membersPlanning poker

Introduction

Story points

Useful tool to assess the effort needed to elaborate a user story.The objective is to assign a value to each user story using acomparative analysis

1 value each story between 1 and 5 (or 10)2 Or use Fibonacci numbers (f0 = 1, f1 = 1, fn = fn−1 + fn−2)

How?discussion among team membersPlanning poker

Introduction

Story points qualities

They are simpleThey are not magicThe team is in control of themThey get your team talking about estimatesDevelopers are not scared of themThey help the team discover exactly what a story meansThey help everyone on the team become genuinely committed

Introduction

Team velocity and sprint planning

VelocityMeasure of the ability of the team to satisfy story points within a singlesprint.

Sprint planning:Select the most valuable stories for which the sum is smaller thanthe velocity (stay below)

Introduction

Running sprint

Let’s consider a general sprint backlog, how do we plan the sprint?Consider the user stories in the sprint backlog and detail them onneeded activities, where each activity does not require more thanone day to complete (2nd planning meeting lead by the SM)group cards together with the user storyproceed iteratively selecting one card per time and move themamong the columns of the backlogif the the sprint ends and there are still cards non fullyimplemented, move them back to the product backlog

Introduction

User stories and activities

Introduction

Story decomposition

Introduction

Sprint Backlog - example

Introduction

still on velocity

How can you define your velocity for a new team at the first sprint?

AlternativesTake data from similar teams, working in similar contestsMake a “random” guessDo not define velocity and postpone the decision

Introduction

still on velocity

How can you define your velocity for a new team at the first sprint?

AlternativesTake data from similar teams, working in similar contestsMake a “random” guessDo not define velocity and postpone the decision

Introduction

Sprint execution and burndown charts

When the sprint starts:Draw a burndown chartreport points acquisition for “done done” storiesin case you add stories to the sprint report it in the chart

Introduction

Burndown chart sample

Introduction

Determining Sprint Length

General Guidelines and Relevant FactorsI No one-fits-all solutions (from 1 to 4 weeks)I Consider customer availability and locationI Consider need for fedbacks and requirements clarityI Consider team ability to decompose workI Consider project durationI Consider established engineering practice within the team

Introduction

How do you know you are done?

“Done” dimensionsI . . . with a storyI . . . with a sprintI . . . release to integrationI . . . release to production

How toI Brainstorming sessionI Categorization session (Development, Testing, Project

Management, Other)I Sorting and ConsolidationI Creation and publishing

Introduction

Release Planning

Does SCRUM suggest to not derive release plans?

I Sketch a preliminary release plan

I Estimated, ordered, and prioritized product backlogI Team velocityI End-of-sprint dates

I Establish degree of confidenceI Revise the plan every sprint

Key to success

I Communicate up front and oftenI Update the release plan after every sprintI Try to do the highest-riority items firstI Refine etimates on bigger itemsI Deliver working software

Introduction

Decomposing stories and tasks

Writing stories and taks of the right size can mean the differencebetween succeeding with Scrum and failing miserably

Setting the stageThree flavors stories – epics, themes, stories

I Redesign the user interface for the document editorI Redesign the menu bar for the document editorI Redesign the edit menu

Tasks should not need more than two days to complete

Introduction

Decomposing stories anda tasks

Rule of thumbs for good decompositionsCan the team estimate the product backlog in story points?Is there clarity on the stories in the backlog?How precise are your stories, and what is the right precision? Is ittestable?Do I understand this story well enough to do it myself?

Introduction

How does a scrum team deal with dependencies between tasks?

This all sound good in theory, but can it really work on a real project?

The “last responsible moment” seems to be a bit risky. Isn’t it a better idea toplan up front, even if that plan has to change?

Don’t programmers suck at planning – especially for projects, which areinherently unpredictable?

Isn’t unrealistic to promise that you will have working software to demonstrate atthe end of each sprint? What if the team is working on something that cannotreally be demonstrated?

Introduction

When we have a bug in our production software, my team has to stop what theyare doing and fix it, and I cannot wait until the end of the sprint to do it. Isn’tScrum being unrealistic about support tasks?

It does not seem realistic to have a Product Owner who has all that authority tomake decisions, all of those connections with customers and the company, andalso so much free time to spend with the team every day. Does not that meanthat Scrum cannot possibly work?

I can see how sprint planning works once the team comes up with estimates, butI am still not sure where those estimates come from. How do teams estimatetasks?

How do you handle global teams?

OK, I get that the Daily Scrum keeps people working on the right tasks. But evenwell-meaning developers can get caught up doing things that are not really thebest use of their time. Cannot Scrum teams still get sidetracked?

Introduction

Bibliography

Andrew Stellman and Jennifer GreeneLearning Agile Understanding Scrum, XP, Lean, and KanbanO’Reilly 2015.

Chapters 4 and 5

software development with...

Documents