SCRUMAgile Software Development

Jonas Flesch - me@jonasflesch.com

WASTE

Never Rarely Sometimes Frequently Always

Research of the Standish Group in the largest US project development firms,

revealed that 64% of features requested by customers are rarely or never used

12 AGILE PRINCIPES

01Continuous delivery and early software

with value: customer satisfaction

02Changes are welcome: competitive

advantage for the customer

03Development in short cycles: frequent

delivery of working software

04Business people and developers must

work together

05Motivated individuals, with support and

confidence

06Face to face conversation is the most effective method of communication

07Working software is the best measure of

the project progress

08Sustainable work pace, no rush and

overtime

09Technical excellence and good design

10Simplicity:

The art of maximizing the unrealized work is essential

11Self-organized teams:

empowerment!

12Continuous improvement: inspection and

adaptation

SCRUM

• Scrum is based on empirical process

• Defined processes say how they should be executed

• When processes are very complicated to define how, empirical processes are recommended

SCRUM

• Transparency

• Inspection

• Adaptation

ROLES: THE SCRUM TEAM

PRODUCT OWNER- Responsible for the backlog and the

value- Ensures the value of work being done

by the team- Ensures that the team understands the

items in the backlog

SCRUM MASTER- Teach Scrum and ensures that it is

followed- Remove impediments

- Eases management of the backlog- Helps in communication

- Facilitates Scrum events as needed

DEVELOPMENT TEAM

- Auto organized;- Multi-functional;

- Does not contain sub-teams.

SCRUM EVENTS

SPRINT• Scrum heart;

• Fixed time (one month or less);

• No changes affecting the sprint goals are performed;

• Does not put or remove people from the team during an Sprint;

• The scope can be renegotiated when more is learned;

PLANNING

• It answers two questions:

• What will be delivered on the next Sprint?

• How the work to achieve the result will be done?

DAILY SCRUM

• What has been achieved since the last meeting?

• What will be done until the next meeting?

• What are the impediments?

SPRINT REVIEW

• Inspects the result of Sprint and adapts the Product Backlog if necessary;

• It is recommended four hours to one month Sprint;

• The Product Owner finds out what was done and what was not done;

• The group collaborates on what to do next;

RETROSPECTIVE• It inspects up as was the Sprint as:

• People

• Relationships

• Processes

• Tools

• It creates a map of gaps and an improvement plan

SCRUM ARTIFACTS

PRODUCT BACKLOG

• Ordered: items are sorted according to priority implementation - in order to maximize customer ROI

• Estimable: judge and form an opinion on the size of the product backlog or a relevant part of it (eg next Sprint or Release.)

PRODUCT BACKLOG

• Emerging: incomplete and dynamic list. The environment evolves and customers and Development Team learn about the product

• Gradually refined: according to the priority

• Top items: smaller granularity, more detail

• Down items: high granularity, minor detail

DYNAMICMyths and Facts

MYTHS AND FACTS: PRODUCT OWNER1. The PO is the "proxy" or customer representative, conveying their wishes to the Development Team

2. Although it should be influenced by different people, the PO is the only one who can modify the Product Backlog

3. The PO must balance the needs and desires of different stakeholders of the project

4. The best PO's own client or someone chosen by him

5. The PO should be only one person - there should be only a decision point on the product to the Development Team

6. The PO usually can accumulate the role of ScrumMaster smoothly

7. The PO should collaborate closely with the Development Team to maximize the value delivered to the customer

8. The PO should charge the Development Team are committed to all items selected for the Sprint are developed

9. The presence of the PO is not mandatory in the Sprint Planning Meeting - simply the Development Team choose items from the top of the Product Backlog

10. The PO is responsible for defining the right product to be developed

1. Myth: The PO is the "proxy" or customer representative, conveying their wishes to the Development Team

2. Although it should be influenced by different people, the PO is the only one who can modify the Product Backlog

3. The PO must balance the needs and desires of different stakeholders of the project

4. Myth: The best PO's own client or someone chosen by him

5. The PO should be only one person - there should be only a decision point on the product to the Development Team

6. Myth: The PO usually can accumulate the role of ScrumMaster smoothly

7. The PO should collaborate closely with the Development Team to maximize the value delivered to the customer

8. Myth: The PO should charge the Development Team are committed to all items selected for the Sprint are developed

9. Myth: The presence of the PO is not mandatory in the Sprint Planning Meeting - simply the Development Team choose items from the top of the Product Backlog

10. The PO is responsible for defining the right product to be developed

MYTHS AND FACTS: PRODUCT OWNER

MYTHS AND FACTS: SCRUM MASTER1. To be effective, the ScrumMaster must have worked as a member of a Development Team

2. The ScrumMaster works for the Scrum be correctly used by teaching and reinforcing the values and rules

3. The ScrumMaster should work to remove impediments to the work of the Development Team, but only those that do not require organizational changes

4. ScrumMaster is the most important role in a project that uses Scrum

5. The ScrumMaster should have good interpersonal skills to facilitate the resolution of conflicts and promote good communication

6. The ScrumMaster must protect the Development Team from outside interference

7. The ScrumMaster must manage the work of the Development Team

8. The ScrumMaster works toward becoming increasingly necessary

9. ScrumMasters who work all hours in that role better carry out their work

10. In an opinion, impose or interfere with work decisions of the Development Team, the ScrumMaster becomes less efficient as facilitator

MYTHS AND FACTS: SCRUM MASTER1. Myth: To be effective, the ScrumMaster must have worked as a member of a Development Team

2. The ScrumMaster works for the Scrum be correctly used by teaching and reinforcing the values and rules

3. Myth: The ScrumMaster should work to remove impediments to the work of the Development Team, but only those that do not require organizational changes

4. Myth: ScrumMaster is the most important role in a project that uses Scrum

5. The ScrumMaster should have good interpersonal skills to facilitate the resolution of conflicts and promote good communication

6. The ScrumMaster must protect the Development Team from outside interference

7. Myth: The ScrumMaster must manage the work of the Development Team

8. Myth: The ScrumMaster works toward becoming increasingly necessary

9. ScrumMasters who work all hours in that role better carry out their work

10. In an opinion, impose or interfere with work decisions of the Development Team, the ScrumMaster becomes less efficient as facilitator

WHAT A USER STORY ISN'T

A MOCKUP

USE CASE

REMINDER

SIMPLE TASK GROUP

WHAT IS USER STORY

WHO?

WHAT?

WHY?

As an <ROLE>, I can/should/would

<FUNCTIONALITY> to <VALUE>

As an buyer, I can SEARCH BOOKS to CHOOSE ONE

AND BUY

ACCEPTANCE CRITERIA

• What will be the format of the alert?

• In which way the alert will be shown?

• Constantly means which frequency?

• How we can know that the order is late?

AN ALERT SHOULD BE CONSTANTLY SHOWN AS THE SOFTWARE DETECTS

AN LATE ORDER

ACCEPTANCE CRITERIA

• Defined the limits of what should be developed for each User Story;

• The Acceptance Criteria guide the team to avoid adding features without value in the functionalities, and at the same time, at the same time ensures the minimum needed to deliver value;

• Are expressed in short and simple phrases;

ACCEPTANCE CRITERIA

• The Acceptance Criterias are added to the User Stories in the refinement sessions of the Backlog;

• Should be written by the Product Owner together with the Team, to obtain a shared understanding of what must be done;

ACCEPTANCE CRITERIA

• The acceptance criteria also guide the team in the definition of Acceptance Tests;

• Acceptance Criteria are part of the Definition of Done.

me@jonasflesch.com

Jonas Flesch