Putting sprint development into operation

www.outsystems.com

Putting Sprint Development

Into Operation

Ensuring the delivery of a sprintJan-2015

www.outsystems.com© OutSystems. All Rights Reserved

Index

1. Goal of this document

2. Challenges of sprint development

3. Team roles

4. Sprint as an assembly line

5. Keep it moving!


1. Goal of this document

This is a practical guide for sprint development. It helps you focus on the main challenges found when

using Agile in the field.

Chapter 2 presents you key points for project success – along with the recommendations to address them

Chapter 4 has a visual diagram with the schedule for sprint activities, following three core principles:

1. sprint starts fully prepared (“ready”)

2. complete delivery with quality within a sprint (“done”)

3. sprint as an assembly line: how sprint activities impact next ones on the chain

Chapter 5 completes the recommendations, focusing on sprint preparation and planning.

In conclusion, the practices here proposed promote a stable, predictable and productive team pace, resulting in quality and timely deliveries and avoiding unsustainable peaks close to delivery milestones.

This document uses, as basis, the OutSystems Delivery Method.

Target audience: Agile Project Managers (including EMs and DMs)



Focusing on the key points for success



Getting business involved and keeping up with the pace

• Especially in companies with little experience on Agile methodologies, ensuring availability of

users and their direct involvement in specific sprint stages can be as difficult as it is crucial for

project success: key-users must, definitely, be part of the team

Tips• Key to guarantee business involvement is an early alignment of expectations: at project kick-off it must be clear why

Agile emphasizes communication and collaboration and all expected points of interaction with key-users must be

presented – and scheduled – along with what regular activities are expected from them and the effort those will take

• Scheduling regular status update meetings with business stakeholders is also highly advised to ensure full alignment

SymptomsThese emerge very soon when key-user availability is not verified: unclear priorities, difficulties preparing a sprint to

start, User Story descriptions full of unverified assumptions, demos not meeting expectations, delivered User Stories are

not accepted by business, key-users feel “not keeping up with the pace of the dev team” … including quality issues

The sprint diagrams provided in chapters 3

and 4 can well be used for this alignment



Preparing a sprint to start

• Which is the same as saying “Meeting the definition of READY before sprint start”

• It must be clear to all team that only US that are prioritized, well defined, estimated and unblocked

from dependencies can be allowed into a sprint

• Definition of DONE for US is also part of sprint preparation: consider that a poor definition of done

means poor value for business in the end

Tips• Planning is key to, consistently, being able to fill a sprint on time while respecting definition of READY

SymptomsFailing at sprint preparation invariably results in failing estimations and/or quality issues as side-effect (for example

when not knowing well the acceptance criteria to meet, or when incomplete definitions and/or poor estimations result in

more effort to deliver, stealing time away from testing...)About the activities involved in sprint preparation:

- Chapter 4 presents a recommended schedule

- Chapter 5 presents tips and best practices

http://www.agilehelpline.com/2011/03/ready.html

http://www.agilehelpline.com/2011/03/definition-of-done.html



Delivering with quality all User Stories of a sprint (and surviving it)

• Which is the same as saying “Meeting the definition of DONE at sprint end” and, we might add,

“without constantly having to resort to unsustainable peaks”

• First of all, this is tighly related with success on the previous challenge: only with good sprint

preparation can the team commit to the US definitions and completion be correctly evaluated

Tips• Proper US estimation and sprint planning are at focus here: besides implementation, estimate and plan time so that

testing and handling feedback (defects but also minor changes) also occur within the sprint

SymptomsWhen a sprint leaves unfinished work, affecting the delivery capacity of next sprints is hardly avoidable: beware of

“snow-ball” effects here resulting on big impacts on the full scope delivery within the available timebox

Chapters 4 and 5 propose a sizing and planning method in order to, given

good sprint preparations, consistently achieve success on sprint delivery

http://www.agilehelpline.com/2011/03/definition-of-done.html



Fitting demo feedback into the timebox

• Agile highlights the need of good US definitions but also the need to adapt and tune, which comes

naturally from the promoted collaboration during demos

• Pre-reserve, in US estimations, effort for handling feedback related to minor changes

• Major changes must result in new US: do check if the initial sizing of the release reserved some

capacity for these (which can occur, depending on the available information and maturity of

requirements at the time of project budgeting)

Tips• Know your timebox! Sometimes it doesn’t fit and timebox control must be strict to quickly show it: “something goes in,

something goes out”

• In these situations backlog negotiation is mandatory to keep it healthy



Improving team performance

• Learning from the experience and immediately applying any resulting lessons to the way that team

is working should not be as hard as changing a tire while driving

• More details are available in the OutSystems Delivery Method, Sprint Development stage

checklist and practices

Tips• Do not underestimate the value of sprint retrospectives: do it regularly within the development team but sometimes

also involving the customer (eventually on a dedicated session), as a way of ensuring full alignment and allowing

improvement also on this side


3. Team roles

Before further analyzing sprint activities let’s have a

quick overview of their executors:

- their main responsibilities

- and recommended availability pattern


3. Team roles: main responsibilities

Key-User• Clarifies processes and prioritizes requirements

• Attends demos and performs acceptance testing

• At least one key-user should have the

responsibility to gather peer consensus and be

their representative

Project Leader• Portfolio, budget and project management

• Prioritizes requirements

Business Analyst• Promotes the complete definition of business

processes next to key-users

• Clarifies processes and prioritizes requirements

towards dev team

• Performs acceptance testing and demos to

business

Tests Coordinator• Defines test plan for each User Story

• Performs acceptance testing

• Coordinates all tests executed on customer side

(including ones done by key-users and BA)

Engagement Manager• Maps business vision to a workable solution

design and architecture

• Maintains stakeholders and team aligned with the

business case and with what users really need

• Fufills the role of Business Analyst or Tests

Coordinator when these are are not available

Delivery Manager• Leads and controls the development team

• Responsible for delivery and for the implemented

technical solution

Developer• Implements the technical solution


3. Team roles: recommended availability pattern

Sprint 1 Sprint 2 ... Sprint n Sol. Release

Pr. Leader

BA

Tests Coord.

EM

DM

Developer

Release X

Key-User

2 x full time

full time

half time

half to full time full time

half to 2 x full time 1 to 2 x full time

10 to 14h / week

5 to 10h / week 8 to 14h / week

Go Live

scenario with an OutSystems Team “Core” with 2 Dev

up to full time if no BA and/or no Tests Coordinator



An assembly line provides a very good analogy to

sprint development:

A stage incorrectly or untimely executed results in

less productivity or quality issues for following

stages



Analysis

Sprint n Sprint n+1Sprint n-1

Int.demo

Userdemo

Delivery Stabilizing

Analysis& Design

Int.demo

Settlement

Testplan

Settl.,

A&DDesign

Settl.,A&D

USclarification Acceptance testing

Acceptance testing

Portfoliomanagement

Settlement

USclarification

Implementation& Testing Stabilizing

Delivery

USclarification

Userdemo

Acc.testing

Settlement

Userdemo

M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F

User

demo

Int.demo

Int.demo

- Activities related to sprint n start on sprint n-1 and finish on sprint n+1

- For a sprint to be fully delivered until its last day all prior activities in the chain must have been successfully and timely executed

- Take special attention also to the recommended schedule for completing the preparation of a sprint before its start

Pr. Leader

BA

Tests Coord.

EM

DM

Developer

Key-User



Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10

Sprint n n+1n-1

User demopresents

Int. demoattends

Acceptance testing

Delivery Demo, testing & stabilizingDesign

US clarification

Int. demoattends

Portfolio management

US clarification

Implementation & testing Stabilizing

DeliveryAnalysis & designInt. demo

presents

Int. demoattends

User demoattends

User demoattends

User demoattends

- Let’s focus on sprint n timeline

- Schedule of activities seems easily achievable, right?

Pr. Leader

BA

Tests Coord.

EM

DM

Developer

Key-User



Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10

Sprint n n+1n-1

User demopresents

n+1 Settl.Priorities

Int. demoattends

n-1 Acceptance testing Acceptance testing

Delivery Demo, testing & stabilizing

n+1 SettlementUS drill-down & sizing

n+1 Settl.

n+1 Settl.Test plan

n+1A&D

n+1 SettlementUS drill-down & sizing

n+1designDesign

n and n+1 US clarification

n-1 Acceptance testing

Int. demoattends

Portfolio management

n+1 Analysis (Processes, US)

US clarification n+1 SettlementUS, Acc. criteria

Implementation & testing Stabilizing

DeliveryAnalysis & designInt. demo

presents

Int. demoattends

User demoattends

n-1 Acc. testing

User demoattends

User demoattends

- Well, this view makes the challenge very clear: during a sprint you also need to manage activities related to previous and following ones

- The acknowledgement and understanding of this reality from all team members is crucial to have a strict and methodical following of a

fully enabling schedule such as the one here presented: otherwise, the risk of not fulfilling all activities and breaking the chain is too high

Pr. Leader

BA

Tests Coord.

EM

DM

Developer

Key-User


5. Keep it moving!

How not to break the chain

in such a tight schedule scenario

(recommendations focusing on sprint preparation and planning)


5. Keep it moving!

Analysis

• The first scope prioritization done during project

Initiation stage provides the candidate US to be

addressed in a given sprint

• Analysis must make sure that those US are well

detailed: this includes crucial aspects such as

following the INVEST principles and, often,

producing screen mockups or activity diagrams

• Results of analysis should be shared in order to

start the sprint settlement step

• More details are available in the Requirements

Gathering sections of the OutSystems Delivery

Method, which are part of the practices for

Initiation and Sprint Development stages

Tips• To avoid impact on other sprint activities and,

therefore, causing a break on the chain, it is very

important that the schedules – such as the one

presented above (and in chapter 4) – are respected

• Considering the potential need of several iterations with

key-users that it involves, analysis phase is especially

prone to delays and must be carefully planned with

key-users


5. Keep it moving!

Settlement

• On the opening session of this sprint preparation

step, the candidate US are presented by the BA

to the EM / DM for solution design, sizing and

sprint planning and to the Tests Coordinator for

the creation of a test plan and scenarios based

on the acceptance criteria defined

• Besides implementation also unit testing,

integration testing and handling feedback

(defects and minor changes) need to be part of

the US estimation and completed within the

sprint – the US must be fully demonstrable and

testable by business by sprint end

• Sizing must be aligned with sprint planning

(following slide presents a method to achieve

this)

• Resulting sizing should be compared to the initial

sizing of the release so that relevant differences,

its causes and any impact on backlog coverage

by the timebox can be aligned with the customer

• On the closing session, EM and DM present the

understanding of US by the dev team and all

team agrees on what will be committed to deliver

in the sprint

• This understanding should also be used as the

basis for distinguishing defects from changes


5. Keep it moving!

Planning

• Define an intermediate delivery / internal demo

point, allowing full implementation and testing to

occur until then but also a stabilization period to

occur after it until the sprint demo to users

• In the stabilization period team should be fully

dedicated to handling first feedback from the

internal demo and to defect fixing (should not be

used for finishing developments)

Given good sprint preparations and sizings, this method should provide

a significant help to achieve success on most sprint deliveries

(without the need to regularly resort to unsustainable effort peaks)

Tips• Correctly balance weight of implementation vs sprint

stabilization according to above objectives

• Rule of thumb would be having the internal demo point

around 70% of the sprint, leaving 30% for stabilization

(the example presented above and in chapter 4)

• To align sizing with sprint planning these factors should

also be used when estimating US

• Although normally stable, the factors could be tuned as

result of sprint retrospective


5. Keep it moving!

After sprint end

• Development team must focus on the topics of the new sprint

• Exception should only be made when an issue needs to be addressed to unblock the acceptance

tests

www.outsystems.com

Thank you!

Nuno Fernandes

Software

Putting sprint development into operation