Agile Project Planning

Tools for Prioritizing Requirements

1. Kano Model: survey end users, use graph - 'delighters' are high value features; new, unexpected - 'satisfiers' bring value to the customer when implemented - 'disatisfiers' are basic customer expectations - non-essentials make no difference/waste of time to develop 2. Priority Matrices weigh prioritization factors using a 2x2 matrix, moving from low to high along both x and y axes Prioritization Factors: - Value - Cost - Risk - Releasability

Completing the Release Plan

1. Splitting (too big) or Combining (too small) Stories 2. Assigning User Stories to Iterations User Stories Should be: - Independent - Negotiable - Valuable - Estimable - Small - Testable Should be able to complete in a matter of days and not the entire Sprint. Split large User Stories using: CRUD Operations 1. Create 2. Read 3. Update 4. Delete Cross-Cutting Technique 1. Security 2. Logging 3. Error-handling Functional and Non-Functional Split Iteration is a Single Development Cycle between 1-4 wks Iteration Planning Meeting - Product Owner, representing User Stories, interacts with Development Team - User Stories - Development Tasks assigned to Iterations - Development Team committment

Agile Estimating Techniques

1. Storypoints - teams perform relative estimation - arbitrary measure between teams - used by scrum teams to determine effort (or size of story) 1. level of complexity 2. level of risk 3. level of effort to implement 2. Ideal Days - more intuitive - units of time to estimate size of user stories - ideal conditions (for single developer w/ no interruptions and all resources available) 3. Relative Sizing - absolute value not considered (no math/time) - cheap and fast estimation technique (ask user implementation experts) 4. Wideband Delphi (developed in '40s by RAND Corp as forecasting tool) 1. Schedule estimation meeting 2. Describing what team is estimating 3. Tasking members to estimate individually 4. Discussing 5. Repeating 5. Planning Poker - build consensus - determine user story size 6. Affinity Estimation - quickly categorizing user stories and applying estimates - product owner, development team, scrum master

Release Planning

A release planning meeting is used to create a release plan, which lays out the overall project goals, objectives and backlog of stories. The release plan is then used to create iteration plans for each sprint. Key Tasks 1. establishing project goals 2. creating user stories 3. prioritizing stories 4. estimating stories 5. grouping stories 6. setting a release date The purpose of the Release planning meeting is to have everyone in the team understand and commit to delivering the agreed release. A release generally fixes only the target date or target scope, but not both since the time and effort to complete all the work is defined only at a high level. The project team and the scrum master are present at a release planning meeting as well as the product owner who determines the priority of items on the release backlog list. A high level estimated road map serves as a base to monitor progress in a project. Release Plan Requirements: 1) Prioritization and estimation backlog 2) Velocity of the scrum team (estimated) 3) Conditions to satisfaction (goals for the schedule, scope, resources) Can be feature driven or data driven

Use Cases (like scenarios)

Actors (person, organization, or external system) represent potential users Create personas to understand users' mindsets as they use or interact with the software. Helps understand how the product might react to particular users as well. Create focus groups. Must base personas on real potential people. Define personal goals. Consider 'negative' personas. Primary (drive decision making); Secondary personas *create 3 or less personas!

Estimating Team Velocity

Actual amount of development work completed (expressed in points) - plan projects by understanding team's capacity - average historical velocity data, unless team's first iteration - run iteration for first time to plan remainder of release - initial velocity steep, then plateaus/stablizes (velocity charts) - increasing velocity can lead to burnout/software bugs Changes in velocity occur due to: - too much focus on team velocity - changes in team structure - technological complexities - miscommunication - changing customer requirements

Prioritizing User Stories Using the MoSCow Model

Categories to identify scope of project 1. Must Have: critical user stories; create backbone 2. Should Have: not critical but important 3. Could Have: useful storie 4. Won't: excluded from scope (but could have in future or "would like to have)

Iteration Planning, aka Sprint Planning

Defines specific goals for next iteration. 1. Confirming user stories and priorities for next sprint 2. Decomposing selected stories into tasks 3. Refining estimates 4. Updating requirements if needed, based on new learning Cone of Uncertainty: decrease of variants over time and estimates; w/ time, less unknowns until no variance Progressive Elaboration helps account for changes in scope, priorities, requirements; understand requirements, users and how they will use the product Scope is extent of work to be completed IOT project is considered complete. Scope creep is uncontrolled change that may result in additional costs. Sacrifice less valuable feature in favor of a higher value one - prevents scope creep.

Storymapping

Organize and present info like roadmap; order users' activities Focus on business value to determine priorities Top axis - high level understanding of system functionality Horizontal axis - based on order of user functions First row - 'walking skeleton' or minimum functionality Successive rows - less functionality 1. Iterative approach to determine release versions at a high level 2. ID scope 3. prioritize backlog 4. ID priorities 5. help planning releases 6. provide open approach 7. ID what to build first

Wireframing

Using storyboards helps visualize user interactions. Wireframes begin depicting requirements visually and ensure teams are on same page. Best Practices: - keep simple - gather feedback - experiment - use storyboards - use annotations - provide explanations (b/c wireframes can't stand on own)