Putting sprint development into operation

www.outsystems.com
Putting Sprint Development
Into Operation
Ensuring the delivery of a sprint
Jan-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
Symptoms
These 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
Symptoms
Failing 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

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
Symptoms
When 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

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
User
demo
Delivery Stabilizing
Analysis
& Design
Int.
demo
Settle
ment
Test
plan
Settl.,
A&D
Design
Settl.,
A&D
US
clarification Acceptance testing
Acceptance testing
Portfolio
management
Settle
ment
US
clarification
Implementation
& Testing Stabilizing
Delivery
US
clarification
User
demo
Acc.
testing
Settle
ment
User
demo
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 demo
presents
Int. demo
attends
Acceptance testing
Delivery Demo, testing & stabilizingDesign
US clarification
Int. demo
attends
Portfolio management
US clarification
Implementation & testing Stabilizing
DeliveryAnalysis & design Int. demo
presents
Int. demo
attends
User demo
attends
User demo
attends
User demo
attends
- 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 demo
presents
n+1 Settl.
Priorities
Int. demo
attends
n-1 Acceptance testing Acceptance testing
Delivery Demo, testing & stabilizing
n+1 Settlement
US drill-down & sizing
n+1 Settl.
n+1 Settl.
Test plan
n+1
A&D
n+1 Settlement
US drill-down & sizing
n+1
designDesign
n and n+1 US clarification
n-1 Acceptance testing
Int. demo
attends
Portfolio management
n+1 Analysis (Processes, US)
US clarification n+1 Settlement
US, Acc. criteria
Implementation & testing Stabilizing
DeliveryAnalysis & design Int. demo
presents
Int. demo
attends
User demo
attends
n-1 Acc. testing
User demo
attends
User demo
attends
- 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

Putting sprint development into operation

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (19)

Andere mochten auch

Andere mochten auch (11)

Ähnlich wie Putting sprint development into operation

Ähnlich wie Putting sprint development into operation (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Putting sprint development into operation

Hinweis der Redaktion