ALM Saturday

Agile planning and portfolio management

su Team Foundation Server

Pordenone - 5 Ottobre 2013

Gian Maria Ricci – VisualStudio ALM MVP

Purpose of the Session

• How to correctly manage «requirements»• How to scale requirement through the

organization• Different level of view for your

«requirements»• Fast feedback and fast cycle

What exactly «Development Team» does

BacklogPrioritized list of everything that might be neededSingle source of requirementsNever complete

Dev Team

Sprint Backlog

My wonderful producthttp://www.url.com

Team like professional Chefs

Backlog -> IngredientsDev Team -> Team of ChefsIncrement -> DishIf the backlog is not good, the product will be no goodThe backlog is the highest value of the productBad Backlog lead to bad increments

The mythical man month

• I believe the hard part of building software to be the specification, design, and testing of conceptual construct, not the labor of representing it and testing the fidelity of the representation.

•The hardest single part of building a software system is deciding precisely what to build

Right size requirements

Independent Negotiable

Valuable Estimable

Sized appropriately Testable

Right Size is importantBig requirements are not estimableA PBI must fit into an iterationBig requirements documentation are a waste in the system

Requirement at Dev LevelHow a requirement is seen by developer

User StoryRequirements as User StoryAs a <role> I want <goal> so that <value>Simple to write, convey core of the conceptIt contains both the needs of the Product Owner as well as the proposed solutionIt is both in the Problem Domain as well in the Solution DomainIt usually do not touch many UI part or many part of the system

As a call center user I want the

system to helps me to insert correct data into the system so I can insert more correct data

in a shorter time.

PBI SizeSize of a user StoryMust be implemented in a single iterationIt should contains enough details to be estimatedIt must give added business value to the productNo dark corner or hidden rocks

As a call center user I want the

system to helps me to insert correct data into the system so I can insert more correct data

in a shorter time.

Estimating PBIAcceptance criteriaChecklist of condition that must be fulfilled to complete the User StoryGood detail level, often based on real action done to the systemCan be composed by a series of Test Cases

When I insert some specific data the system should suggest me the right data to insertCity Names: after the first two letters a suggestion box with compatible city names should appearZIP CODE: Should be automatically populated upon city insertion….

• Type two letters in the City textbox and a suggestion list should appear

• Typing invalid city (ignoring suggestions )turns the textbox Red

• Upon valid city population Zip Code should be automatically set

• …

OR

Backlog in TFSHow to manage Backlog in Team Foundation Server

Requirement at management LevelHow a requirement is seen by management people

EpicsWhen a User Story Become Too BigDecompose in smaller User StoriesPropose alternative smaller solution (T-Shirt Sizing, Rock Sizing, etc)Do not lose the original value The story become an Epic

Es: Implement heuristics to validate dataReally big User StoryMany possible solution of different sizeMany part of the system involvedBut It is a clear Business Value

Implement Euristics to Validate

Data

Epics in form of User Story

Form of user Story is still validThe form “As a <role> I want <goal> so that <value>” is still validIt is more generic and conveys a broader conceptsIt contains mainly the needs not the solutionsIt is almost entirely in the Problem Domain

As a Manager of the Call Center I want the system to suggest to Call Center Users potentially bad data with some form of heuristics. I want also the system to scan actual data to warn for suspicious data The system should make it simple to identify and correct potential errors.

Epics acceptance criteriaWhen an epics is Done?Acceptance criteria are similar to PBIs, just more genericAn epic has several PBI as Childs Not all Childs needs to be finishedKanban board can helps you out

• Manager can find quickly suspicious data • Manager can fix the data and this should make the system "learn"

from this error• Call Center Users should be warned (not blocked) when heuristic

find some problemsNice to have• Heuristic should also "suggest" correction to the data• Once some Manager does a fix, the system should propose similar

fix in the system

Epics in TFSHow to manage Epics in TFS thanks to Enterprise Agile Planning or Portfolio Management

Executive RequirementsVision of the productContains general directions of the productsInvolves investments and funding teamsCould comprehend many teams across organization

Requirement metaphor breaks downThere are vague acceptance criteria. Es. The system should guarantee maximum degree of data correctnessNeeds lots of investigation, risk analysis, planning for internal resourcesIt has no certainty of being implemented (Es. cancellation after risk analysis)

Needs relation to other artifactsDecomposed in Epic and User StoriesProgress trackingIn agile world usually called Themes

Agile ThemeAnalysis of a Theme Identify the general needsAssess the current status of the productAnalyze risks and countermeasuresEstimate ROI of the theme or Business ValueExpress the Vision and Goal with few and simple sentencesA3 problem solving type of analysis (Es Toyota)

Planning and managing running themes Have a clear and ubiquitous Risk managementDecompose in Epics that in turns will be decomposed in PBI/User StoriesPrioritize EpicsDefine Acceptance Criteria for the EpicsMonitor progress of Epics

Theme in TFSCustomization of template and Enterprise Agile Planning

Kanban and LeanFlow of statesEach element flow from a status to anotherEach column has a maximum Work In Process LimitVisual and immediate feedback of how the backlog is evolvingIt is a pull process not a push process

New Analysis Ready Committed Testing Done

Kanban in organizationKanban for epicsSame structure applies to epicsIt can potentially aggregate multiple backlog

New Active Preview Acceptable Closed

Kanban in organizationKanban for ThemePrioritization of visions

New In progress Done

Chain of consequenceThemesThemes are decomposed in epicsWhen a theme transition to in progress it actives its epics

EpicsEpics are decomposed in PBI / User StoriesPrioritized in order to fulfill the vision of the ThemeWhen Epics transition to in progress is actives its PBI

PBIPrioritized to fulfill EpicsDeveloped with self organization by teamsCommon cadence

Using Multiple teams in TFSHow TFS 2012 handles multiple team with different types of self organization

Drum – Buffer - RopeIterative is the keyMultiple team can have multiple backlogs but they share a single drumAll teams are synchronizedDevelopment is iterative to gather maximum transparency and feedback

Backlog

Feedback

Developing Backlog Grooming

Backlog is aliveBacklog groomingAt team level it occurs each SprintEpics backlog usually span for multiple sprintThemes persists for month or even one or two years

FeedbackBacklog is fueled by feedbackFeedback for iterationEarly feedback with UI Mockup

Feedback toolGathering feedback with TFS

Question?