1. Extreme Planning: Agile turned to the max DevDay.LK Johannes Brodwall @jhannes

2. This talk is about

3. What’s this thing we are building?

4. Use that understanding to plan the work

5. A simple way to measure progress

6. (that works just as poorly, but is simpler)

7. After this talk

8. Uncover what needs to be done

9. Forecast from actual progress

10. Plan ourself out of the rush

11. But first

12. Where does the rush come from?

13. Part I

14. Yesterday’s weather

17. “How long will it take to drive to Chicago”

18. Kandy

19. t = s/v

20. After 1 hours, we have only got to Mahara…

21. v estimate > v measured

22. Product backlog

23. 8 8

24. 8 weeks?

25. 8 sprints?

26. 5 stories planned

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

31. 5 stories planned

32. 4 stories delivered

33. 6 stories delivered

34. 7 weeks

36. How many hours?

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

39. Architect

40. The worst way to answer: To estimate hours per task

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

42. Actual hours = Σ estimated hours per task * whatever

43. Part II

44. Creating the backlog

45. Vision Usage flow Product backlog

46. Vision, stakeholder

47. 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

48. 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 emails Our product lets them keep track of leave days available and team leaves

49. Employee Team lead PMOHR Leave-IT HRDB SSO

50. Usage flow

51. 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 email 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 email 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

52. Minimum interesting demo

53. 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 email 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 email 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

54. Product backlog

55. 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

56. Experimental X Simplified X Basic X Complete X Polished X

57. Demo/deploy/automate Styling Testing Learning

58. Step 4 Step 3 Step 2

59. Experimental X Simplified X Basic X Complete X Polished X

60. Release/ deployment Architecture through spike Technology study

61. EstimatePlan

62. Part III

63. Planning the sprint

65. Planning the demo

66. (content)

67. 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

68. 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

69. Log in using Exilesoft SSO (foreign user story from SSO) 1.Delete any existing permission from https://security.google.com/settings/security/permissionshttps://security.google.com/settings/security/permissions 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 email address is displayed 11.Click log out 12.Verify that user email address is no longer displayed

70. Planning the demo

71. (time)

73. Planning the demo

74. (practice)

75. Log in using Exilesoft SSO (foreign user story from SSO) 1.Delete any existing permission from https://security.google.com/settings/security/permissionshttps://security.google.com/settings/security/permissions 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 email address is displayed 11.Click log out 12.Verify that user email address is no longer displayed

76. What are we doing? When are we done?

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

78. Create backlog from usage flow

79. Track stories per week Forecast Actual

80. Plan features with demo script

81. johannes@brodwall.com http://JohannesBrodwall.com http://twitter.com/jhannes Thank you

82. 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)

83. 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

84. 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

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