Extreme Planning: Agile turned to the max DevDay.LK Johannes

This talk is about

What’s this thing we are building?

Use that understanding to plan the work

A simple way to measure progress

(that works just as poorly, but is simpler)

After this talk

Uncover what needs to be done

Forecast from actual progress

Plan ourself out of the rush

But first

Where does the rush come from?

Part I

Yesterday’s weather

“How long will it take to drive to Chicago”

Kandy

t = s/v

After 1 hours, we have only got to Mahara…

v estimate > v measured

Product backlog

8 8

8 weeks?

8 sprints?

5 stories planned

(or 5 stories * 3-8 story points = 25 story points)

5 stories planned

4 stories delivered

6 stories delivered

7 weeks

How many hours?

Cost = (burn rate) * (time) = (team cost) * (backlog) / velocity

Architect

The worst way to answer: To estimate hours per task

Actual hours = Σ estimated hours per task * “load factor” * “management overhead” * fudge factor

Actual hours = Σ estimated hours per task * whatever

Part II

Creating the backlog

Vision Usage flow Product backlog

Vision, stakeholder

For some stakeholder Who wants achieve some goal The ??? system Is a type of application Which lets them perform some actions. Unlike most relevant alternative Our product has some advantage

For company employees Who wants to take leave from work The Leave-IT system Is a responsive web application Which lets them register leave applications and get them approved Unlike sending s Our product lets them keep track of leave days available and team leaves

Employee Team lead PMOHR Leave-IT HRDB SSO

Usage flow

1.HR admin logs in via SSO (same for the other stakeholders) 2.HR admin navigates to Leave-IT 3.HR admin allocates leave quotas based on information in HR database 4.HR admin builds company calendar 5.HR admin adjusts the leave quota for an individual user in HR system 6.HR admin assigns leave approvers from uses in HR system 7.Employee views their available leave 8.Employee submits leave request 9.Leave-IT notifies Team leader of a new pending leave request via 10.Team leader views pending leave applications 11.Team leader checks the other leaves in the same time period 12.Team leader approves leave 13.Leave-IT notifies Employee of an update of his leave request via 14.Employee checks status of own leave application 15.Employee cancels own leave 16.PMO views the teams' leave calendar, plans and history 17.PMO may cancel leave if necessary

Minimum interesting demo

1.HR admin logs in via SSO (same for the other stakeholders) 2.HR admin navigates to Leave-IT 3.HR admin allocates leave quotas based on information in HR database 4.HR admin builds company calendar 5.HR admin adjusts the leave quota for an individual user in HR system 6.HR admin assigns leave approvers from uses in HR system 7.Employee views their available leave 8.Employee submits leave request 9.Leave-IT notifies Team leader of a new pending leave request via 10.Team leader views pending leave applications 11.Team leader checks the other leaves in the same time period 12.Team leader approves leave 13.Leave-IT notifies Employee of an update of his leave request via 14.Employee checks status of own leave application 15.Employee cancels own leave 16.PMO views the teams' leave calendar, plans and history 17.PMO may cancel leave if necessary

Product backlog

1.Experimental submit leave 2.Experimental show leave status 3.Simplified layout and style 4.Simplified approve leave 5.Simplified view leave request 6.Simplified submit leave

Experimental X Simplified X Basic X Complete X Polished X

Demo/deploy/automate Styling Testing Learning

Step 4 Step 3 Step 2

Experimental X Simplified X Basic X Complete X Polished X

Release/ deployment Architecture through spike Technology study

EstimatePlan

Part III

Planning the sprint

Planning the demo

(content)

Experimental submit leave request 1.Go to the front page 2.See that there is a dropdown with possible users and approvers 3.Select a user, approver, start date, end date, reason 4.See that the number of days is updated 5.Click submit 6.See that the data is in the database 7.Submit a request with no start or end date 8.See that there is an error message 9.See that the data is not in the database

Log in using Exilesoft SSO (foreign user story from SSO) 1.Open a new web browser and go to the application 2.Verify that the user is not logged in 3.Click login 4.The user is sent to Exilesoft SSO 5.Verify that the username is correct when the user is returned to application TODO SSO must support cross-domain authentication

Log in using Exilesoft SSO (foreign user story from SSO) 1.Delete any existing permission from 2.Open a new web browser and go to the application 3.If you are logged in, click log out 4.Click login 5.The user is sent to Gmail to authenticate 6.Deny the authentication request 7.Verify that the login button is still displayed 8.Click login again 9.Allow the authentication request in Gmail 10.Verify that the users address is displayed 11.Click log out 12.Verify that user address is no longer displayed

Planning the demo

(time)

Planning the demo

(practice)

Log in using Exilesoft SSO (foreign user story from SSO) 1.Delete any existing permission from 2.Open a new web browser and go to the application 3.If you are logged in, click log out 4.Click login 5.The user is sent to Gmail to autenticate 6.Deny the authentication request 7.Verify that the login button is still displayed 8.Click login again 9.Allow the authentication request in Gmail 10.Verify that the users address is displayed 11.Click log out 12.Verify that user address is no longer displayed

What are we doing? When are we done?

Cost = (burn rate) * (time) = (team cost) * (backlog) / velocity

Create backlog from usage flow

Track stories per week Forecast Actual

Plan features with demo script

Thank you

Context –“We get a tender with epics and need to give a price” (Janini, Virtusa) –We have a team that is “confused” – beginning or halfway through Get a team together and discuss the who, why, what (actions) and alternatives (vision statement) Use actions to start the discussion of the usage flow (a narrative that starts with the first interaction with the (sub)system and ends when the business value is produced) Create the product backlog from the usage flow. I like the items on the product backlog to be man- week sized. Each action from the usage flow goes into the product backlog. In addition, the product backlog should contain activities for layout, deployment, specific testing etc. –Separate different iterations on the same increment in time to accumulate feedback –Prioritize the items for the first internal demo, first external demo and first trial deployment –Simplified user stories can be used to detach teams This gives a list which length predicts the number of weeks. Weeks = # Items / number of item producers. Hours = Weeks * Burn rate Tracking –As project proceeds, track actual progress (count of items per week) versus forecasted progress. Also track changes in total scope. This will adjust the forecasted times and costs. –Demonstrate with the customer whenever you can. This will determine if the quality matches their expectations –Deviation in progress, changes in scope or missed expectations mean you should discuss contract with customer or suffer consequences Focus through demo planning –In scrum planning, when you know the scope, come up with a screenplay script for the demonstration. Get someone brave to give a mock demonstration during the planning. => Focus on the outcomes –Use the demo focus to help the team break down technical dependencies –Practice the demo towards the end of the sprint –Give a demo like you mean it, but don’t lie (unless you want to delude the value of the feedback)

Planning – man-week sized items –Gather “everyone” to discuss => usage flow –Usage flow actions x revisits (experimental, simplified, basic, complete, polished), technical items (layout), releases => product backlog (releases planned in time) Revisits with different expectations (experimental, simplified, basic, complete, polished) – also used to avoid deps Technical items with visible results Releases –Product backlog => time and cost (t = s/v) Tracking every week –Actual production, changes in scope –Demonstrations with customers => expectations –Progress, scope, expectation/insufficient done-ness => risk Accelerating with demo –Practice mock demo during planning Example project: Planning Monday, Demo rehearsal Friday morning, Demo Monday morning –Use demo driven work to focus on feature slices (avoid deps) –Demonstrate with externals to get feedback

Planning – man-week sized items –Gather “everyone” to discuss => usage flow –Usage flow => product backlog –Product backlog => time and cost (t = s/v) Tracking every week –Actual production, changes in scope –Demonstrations with customers => expectations –Progress, scope, expectation/insufficient done-ness => risk Accelerating with demo –Practice mock demo during planning –Use demo driven work to focus on feature slices (avoid deps) –Demonstrate with externals to get feedback

TODO Need better example project (Architecture – don’t play) Team-mbedded product management