Here is a typical sequence for release planning: - Introductions - name, role, expectations, concerns - Vision - sponsor speaks. Elevator Pitch. Product Box. - Problem statement - Why build it: what problem are we solving - Business case - What are the business drivers, business case, expected benefits - Scope - High Level Scope - In/Out/Undecided - Key trade-off policies: time vs cost vs scope vs quality vs ux - Schedule expectations / Important dates - Project context – departments, 3rd parties - Customer & UX - Who are we building for: who are the customers, users, user roles, their needs and goals review any UX prototypes. paper prototyping. Review As-Is systems and identify pain points and opportunities. - Build the product backlog - capture and agree the product features using task mapping or process flows. Create initial high level “epics” as minimal marketable features. - Solution design - high level architecture and estimation assumptions - Team – team size, roles, responsibilities - Approach - methods, policies, values, principles. - Sizing - Establish high level estimates for each “epic” - relative "points" estimation - Calibration - Costing & Resourcing - forecasting development capacity - Prioritisation - Prioritise the initial release product backlog features - define the first release as a minimal viable product. Consider story mapping or buy a feature techniques. Create a release roadmap. - Presentation - present outputs to the wider stakeholders - consider collecting and summarising the outputs as a single “project inception” slide deck Some guidelines: - Focus on establishing clear shared understanding across the whole team - Co-locate the whole team for the initial project kickoff especially for distributed/offshore projects - Include all departments and all roles - operations, developers, sales, support, business, BA, QAs - Consider conducting a series of workshops (“kick off”, “estimation” & “release planning”) - Use an experienced facilitator - Use visual models: whiteboard sketches, paper prototypes, flipcharts, card sorting, story mapping. - Do “just enough” to get the next release defined: days not weeks. - Use time between workshops to resolve outstanding questions, do technical research - Capture the outputs - take photos of all the workshop outputs / whiteboards |
scrum phases >