25 Levels of Planning Product Vision Product Roadmap Release Plan Adapted from “5 Levels of Agile Planning” by Hubert SmitsProduct VisionProduct RoadmapRelease PlanGood agile teams plan. They just don't plan more than they need to (or less). They wait until the last responsible moment to make the commitment / decision.Iteration PlanDaily Standup
3Iteration Planning Define scope as a team Define a clear understanding of “done”Plan just enough that you can commitThis is the first level where you actually commit (at the team level). You plan out what you're going to accomplish in the next iteration (a matter of weeks). You get a clear understanding on what done is (acceptance criteria).Scrum-ban has the potential to change thinking on this. Pull as you need. No estimation / commitment.
5Product Owner Prioritizes the backlog Communicates what is important … and what is notIs a proxy for the customer and other stakeholders
6Scrum MasterResponsible for the processFacilitates the meeting
7Team MemberAsks questionsCollaborates with othersSigns up for work
8The Backlog A ranked list of stories What is a story? A scenario that we must do work to implement which results in business valueTypically in the form of: “As a <type of user>, I want <feature> so that <business value>”Good stories meet the INVEST criteriaMike Cohn proposes this form of story naming.Bill Wake came up with the INVEST model.
9Before you Start Well Groomed Product Backlog Prioritized Estimated Iteration Theme/GoalEstimatedPrioritized
10Exercise 1 Create a prioritized backlog As a <user> I want <feature> so that <business value>Estimate relative sizeAt least enough for one iterationChoose any domain you likeWe’ll use the results in a future exerciseWhat’s your goal for the iteration?
11A Typical Iteration Planning Session Discuss LogisticsReview Iteration GoalsUnderstand the StoriesTask Out the StoriesCommitTypical Duration: 3-4 hoursAttendees:Product ownerScrum masterDelivery teamMaterials:Stories (cards or online)Task planning material (cards, whiteboard, online)Planning/estimation materials (e.g. planning poker cards)
12Discuss Logistics Review Historical Velocity Review Team Availability Holidays / VacationsMeetingsL3 Support, outside commitment, etcReview the Definition of Done
13Definition of Done You need to define for your environment Definition will evolve over timeExample:Unit tests written and passedAcceptance tests automated and passedUser facing documentation writtenChecked in to the buildNo defects introduced
14Review Iteration Goal(s) Product OwnerExplain the Goal (theme)Make priority adjustments based on feedback from delivery teamTeam MembersASK QUESTIONSUnderstand the Goal, not just the desired features
15Understand the Story Product Owner Team Members Explain the Story Explain the “Why” (“as a <role> I <what> so that <WHY>”)Break down as neededElaborate on acceptance criteria/testsMake priority adjustments based on feedback from teamTeam MembersUnderstand the storyUnderstand and question the acceptance criteria (how will you build a test for each? What about…)Validate the size/implementability
16Acceptance Criteria What is required for the success of this story? Typically determined at iteration planning jointly between product owner, dev, QA, writers, etc.
17Task out the Story Define tasks Estimate the work involved Validate capacity againTrack velocity from iteration to iteration so you can learn from past experience.The Product Owner can help in avoiding less valuable work
18Hold Off On NamesKeeps everyone focused on all the tasks, not just theirsEncourages team commitmentWithin the iteration, encourages focus on prioritiesAnd teamwork
19RepeatUntil the team cannot take on moreSplit stories as necessary
20Splitting a StoryThe closer to the present a story is, the smaller it will becomeThose for this iteration need to fit within the iterationWhen splitting a story, each “slice” should add incremental user value
21Commit Everyone agrees the iteration is doable Use disagreement and uneasiness in team members to drive out hidden risks, tasks, and issuesDrive agreement with a fist of fiveAbsolutely, no questionI think this is good and will make it happenI can support thisI’m uneasy about this and think we need to talk about it moreLet’s continue discussing this idea in the parking lot
22Effective Meetings Everyone should be focused on the task at hand No working on laptopsEvery minute should be valuableIf not, figure out how to make it so
24Exercise 2 Do iteration planning Go through stories in priority order Create acceptance criteriaTask outStop when you can’t do moreCommitDo you believe in your result?
25EstimatingIdentify 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 storyTackle as a team; Planning poker can help (www.planningpoker.com)
26Why Story Points? Time estimates Story points Vary by person Encourage paddingTend to grow staleStory pointsMore consistent from person to personNot a commitment to time frameDon’t change as muchEasier to estimate relative size
27VelocityNow 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
28Release Planning Deliverables Plan for each IterationAssumptionsDependenciesRisksAre things synched up across teams?Are you attacking the most important stories?Does the team believe in the results?Iteration PlanHigh level stories for each iterationName based on what the user gets out of that storyEstimates for each story (in terms of how many people for that iteration)AssumptionsDependenciesRisks
29Coordinating TeamsSimplest if one team has the skills to take on an item by themselvesIf not, try to minimize the gapWithin the same iteration is idealTouch base before and after iteration planningDaily scrum of scrum meetings can help
30KanbanInstead of planning it all up front, you can pull things in as you goKeep iterations (Scrumban) or not (pure Kanban)AdvantagesMore flexibility (great for start ups and support)DisadvantagesLess predictabilityHarder to coordinate
31Questions? Walter Bodwell Planigle email@example.com