Release Planning

Agile ExpectationsWalter BodwellPlanigle

1An Introduction Walter BodwellFirst did agile at a startup in 1999Got acquired by BMC in 2000 and spent the next 8 years doing agile at scaleNow providing consulting, tools and training to help teams get the most out of agile at Planigle

25 Levels of PlanningAdapted from 5 Levels of Agile Planning by Hubert SmitsDaily StandupIteration PlanRelease PlanProduct RoadmapProduct Vision3Product VisionWhat are you trying to accomplish?How is that going to benefit the business?Daily StandupIteration PlanRelease PlanProduct RoadmapProduct Vision4Product RoadmapHigh level themes for the next few releasesShows progress towards strategyLots of wiggle roomDaily StandupIteration PlanRelease PlanProduct RoadmapProduct Vision5Release PlanGo into next level of detail towards themesGet everyone on the same pageUnderstand what you will likely achieveBalance load between the teamsA projection, not a commitmentDaily StandupIteration PlanRelease PlanProduct RoadmapProduct Vision6TimingRelease planning should occur just before the teams start on the release

If teams are just forming, delay until after the teams have done 2 or 3 iterations (so that they understand their velocity)

If the release is long (over 4-6 months), release planning might occur multiple times to resynchHigh fidelity for close itemsLow fidelity for items further out

Preparing for Release PlanningSet themesPrepare the backlogIdentify teamsDivvy stories upUnderstand the issuesSize the storiesDefine what done isIdentify key dates

8Set Themes / Investment AreasWhat are the areas were going to invest in for this release?

Themes give you room to be flexibleWe know were going to do somethingWell decide as we go how much

Themes are a great way to communicate the focus of the release without prematurely committing you to details

The BacklogRank order thingsEach should meet I.N.V.E.S.T. criteriaSize will vary based on how far out

10Why Prioritize?

11Identifying TeamsIt is preferable to have each team have the ability to complete its work by itselfIn other words, instead of a team per component, have teams with members who have knowledge of each component that will need to change to deliver somethingDont change the teams frequently

12Component teams provide expertiseBut limit the ability to attack the highest prioritiesAnd require more coordination (complexity)Components or Features?

13Divvying Things UpYour goal is to divvy things up so that teams are working on items of around the same priorityBadGoodIf each team ableto get 3 blocks in the release,the highlightedstories wontmake itBy better distributingstories amongst theteams, look whichstories wont make itDependenciesApproaches (go with the first one you can):Structure the teams so that a single team can solve the problem end to endDo the work within the same iterationImplement the service and then use itStub out the service and implement it later

Make sure the dependent teams(including external ones) are represented atrelease planning

Understanding the IssuesKeep to the minimal responsible amount of doc

No more than you need at any point in timeJust enough to understand dependencies and mitigate risksThe right size for the problem

Do you need this now?If not, try to reduce or eliminate it

16Agile ArchitectureJust enoughRefactor as you go

17EstimatingIdentify a medium sized story that is well understood; call it a 5Now estimate other stories relative to thatIs it about the same, as difficult, twice as difficult?Use Fibonacci numbers: 1, 2, 3, 5, 8, 13, 21If bigger than that or if too hard to estimate, split the story

18Why Story Points?Time estimatesVary by personEncourage paddingTend to grow staleStory pointsMore consistent from person to personNot a commitment to time frameDont change as muchEasier to estimate relative size

19VelocityNow that stories have sizes, you can track how many points you typically get done in an iterationYou can now use this to predict future completion rates

20Story Points Across TeamsTo get teams in the same ballpark, pick a baseline storyEach team should understand the complexityChoose a medium size storyCall it a 5All other stories are relative to it

Dont compare velocityUsed by a team to evaluate itselfIf others use it for evaluation, it will be gamed and become useless

Definition of DoneDefine what Done means for your teamMake Done more stringent over timeDefinition of Done evolves as you do

22Key DatesHow many iterations?When do they start / stop?Which iterations (if any) are hardening?Any other dates to be mindful of?

Release PlanningKick off / OverviewBreak Out SessionsReview Results

24AttendeesProduct OwnersScrumMastersArchitects / LeadsQAWritersOther Stakeholders

This is the best time to travel!

25Release Planning DeliverablesPlan for each IterationAssumptionsDependenciesRisks

26PhilosophiesSimple Is BetterAllows for better coverage across featuresPrevent unnecessary complexityIf you go too simple, it will remain unused until you follow up with the market demanded features next releaseIf you go too complex, it is very difficult to identify and remove the unnecessary complexity

Leave Room To Be AgileNo more than 70% of our time should be allocated to committed features

27Release Planning Wrap UpGo through each iteration for each teamAre things synched up across teams?Are you attacking the most important stories?Does the team believe in the results?

28Is This Reasonable?Everyone agrees the release is doableUse disagreement and uneasiness in team members to drive out hidden risks, tasks, and issuesDrive agreement with a fist to fiveAbsolutely, no questionI think this is good and will make it happenI can support thisIm uneasy about this and think we need to talk it out some moreLets continue discussing this idea in the parking lot

29After The MeetingCapture the results in your tool of choiceUpdate after each iterationNotify of major changes to the plan

30Communicating the FutureThemes give you room to be flexibleIf a customer is asking about a particular feature, you can get into a discussion of prioritiesDemos are a potential opportunity to get a customer involvedSmaller, incremental releases generate feedback on what to dig into in more detail31Prioritization Doesnt StopThe product owner re-prioritizes after each iterationWeve learned more about the businessLets take advantage of thatThe further down the list something is, the less defined it will be and the less important it is to prioritize precisely

32Questions?

Walter BodwellPlaniglewbodwell@planigle.comTwitter: @wbodwellwww.planigle.comwww.walterbodwell.com33