Agile + Planning Poker

Transcript

1. Agile + Planning Poker Héctor Benítez - Nearsoft
2. Who am I? Héctor Benítez @hectorbenitez hbenitez[at]nearsoft.com Software Developer at Nearsoft Agile enthusiast, but not Scrum Master :) Lead Developer at PlanningPoker for Hangouts http://planningwithcards.com
3. * • Methodologies that choose to do things in small increments/Iterations. • Each iteration is worked on by a team through a full software development cycle, including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a version is demonstrated to the stakeholders. Agile
4. * Agile Manifesto www.agilemanifesto.org We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interaction over Processes and tools Working software over Comprehensive documentation Customer collaboration over Contract negotiation Responding to change over Following a plan
5. * An iterative development framework in which a project takes on a set of features that it can be implemented within a 1-4 weeks “sprint”. Scrum
6. * • Stories describe what the customer wants using the customer’s language and perspective (e.g., ability to add a new user). • A story is something that add value to the customer rather than an activity or task. Stories
7. * • Is a definition of features that can be implemented by the team within a timeframe from 1 to 4 weeks, sprints duration are defined according to the project size and level of feedback required. Sprint
8. * Scrum Static Model
9. * •Product Owner •ScrumMaster •Team Scrum Roles
10. * • Represent the voice of the customer. • Makes sure that The Team work with the right things from a business perspective. • Write stories, prioritizes them, and place them in the product backlog. • Manage project features and releases to optimize ROI. • Inspects increment and make adaptations to project after end of sprints. • Can change features and priority every X days, but not in the middle of a sprint. Product Owner
11. * • Scrums are facilitated by a ScrumMaster, primary job is to remove impediments. • The ScrumMaster is not the leader of the team but act as a buffer between the team and any distracting influences. • Enforcer of rules. Scrum Master
12. * • The team is a cross-functional group of people responsible for managing itself to develop the product. • The team has the responsibility to deliver the product. The Team
13. * Management responsibilities are divided among all the roles Management?
14. * • Sprint Planning • Daily Scrum • Scrum of Scrums • Sprint Demo • Sprint Retrospective Meetings
15. * • Held at the beginning of the sprint cycle. • Select what work is to be done. • Prepare the Sprint Backlog that details the stories that will be included in the Sprint and their estimates. • Identify and communicate the plan for the Sprint. • Limited to eight hours, max. Sprint Planning
16. * http://www.planningwithcards.com/ Story points Planning Poker
17. * • The team every day during the sprint ◦ Start precisely on time ◦ All are welcome, only pigs may speak ◦ Time- boxed to 15 minutes ◦ Same location, same time every day • During the meeting each team member answers 3+1 questions: ◦ What did you do yesterday? ◦ Did you run into any obstacles? ◦ What are you planning to do today? ◦ Is there anything that may prevent you from accomplishing your goal? Daily Scrum
18. * • Held every day normally after the daily scrum ◦ These meetings allow clusters of teams to discuss their work, specially overlap and integration. ◦ A designated person from each team attends. • Same agenda as daily scrum plus ◦ What has your team done since we last met? ◦ What will your team do before we meet again? ◦ Is anything slowing your team down or getting in their way? ◦ Are you about to put something in another team’s way? (dependency management). Scrum of Scrums
19. * • Held at the end of the sprint cycle • Review the work that was completed and not completed. • Present the completed work to the stakeholders (aka the demo). • Limit to four hours. • Challenges? Sprint Demo
20. * • All team members reflect on the past sprint. • Make continuous process improvements. • Two main questions are asked in the sprint retrospective ◦ What went well during the sprint? ◦ What can be improved in the next sprint? • Three hour time limit Sprint Retrospective
21. * • Scrum artifacts ◦ Product Backlog ◦ Sprints Backlog ◦ Whiteboard • Additionally some metrics per sprint ◦ Velocity ◦ Estimated vs Actual ◦ Bugs found ◦ Any other metric important for you Artifacts
22. * • The features or user stories list that the product owner wants. • The product owner is responsible for the contents, prioritization, and availability of the product backlog. • The development team is responsible for estimates and assumptions as needed for every product backlog item. Product Backlog
23. * Product Backlog
24. * Product backlog
25. * • The work or features that the team defines to be delivered in each sprint. • Which backlog items go into the sprint is determined during the sprint planning meeting. Sprint Backlog
26. * NOT CHECKED OUT CHECKED OUT DONE SPRINT GOAL UNPLANNED ITEMS NEXT WITHDRA WN WITHDRA WN WITHDRA WN Fix memo ry leak Write failing test MIGRATIO N TOOL BACKOFFI CE LOGIN BACKOFFI CE USER ADMIN Write failing test 2 d DAO DB design 2 d 1 d Intege r test 2 d 0.5 d DEPOSI T Code cleanu p 1 d Write Failing test 1 d GUI spec 2 d Tapes try spike 2 d 1 d Write Failing test 2 d Tapes try spike 2 d 1 d Impl GUI1 d Integr ate With JBoss 2 d Write failing test 3 d GUI Desin g (CSS) 1 d Clarify Requir e- ments 2 d Impl GUI6d Sales Suppo rt 2 d Write White- Paper 4 d BETA-READY RELEASE BURNDOWN Whiteboard
27. * NOT CHECKED OUT CHECK ED OUT DON E SPRINT GOAL BURNDO WN UNPLANNED ITEMS NE XT WITHDRA WN WITHDRA WN WITHDRA WN Fix memo ry leak Write failing test MIGRATIO N TOOL BACKOFFI CE LOGIN BACKOFFI CE USER ADMIN Write failing test 2 d DAO DB design 2 d 1 d Intege r test 2 d 0.5 d DEPOSI T Code cleanu p 1 d Write Failing test 1 d GUI spec 2 d Tapes try spike 2 d 1 d Write Failing test 2 d Tapes try spike 2 d 1 d Impl GUI1 d Integr ate With JBoss 2 d Write failing test 3 d GUI Desin g (CSS) 1 d Clarify Requir e- ments 2 d Impl GUI6d Sales Suppo rt 2 d Write White- Paper 4 d BETA-READY RELEASE Whiteboard
28. * • Velocity is a metric that predicts how much work a team can complete within a two-week sprint (or similar time-boxed period). • Bugs. • Estimated vs Actual. Metrics
29. * Scrum Dev & Test Process 11 12 13 14 15 16 Specs/ Wireframes Overall Model Product Backlog Sprint Blocks Sprint Execution and Testing Product Increment 24 hrs 2-4 Week s Product owner: - Articulates product vision - Prioritizes list of what’s to be done Team: - Clarify, understand and estimate every backlog item - Commitment-driven and capacity-based sprint planning - Requirements clarification - Fit features into sprint - Goals definition for sprint - Create production code - Testing strategy - Testing, Development , Staging environments - Continuous integration - Automated testing - Unit testing - Code reviews - Bug fixing - Technical debt - Progress tracking - Daily meetings - Promote to production - Release manifest - Update reporting backlog (metrics) - Retrospective meeting
30. * • Iterations must have fixed time boxes and be less than 4 weeks long. • After completing the sprint, everything must be ready to go into production. • A Scrum team must have a Product Owner and know who that person is. • The Product Owner must have a Product Backlog, with estimates and assumptions created by the team. • There must be no one outside a team interfering with the team during a sprint: ◦ No allowed to work on other projects unless is planned. ◦ All the team must be working focused on features defined in the current sprint, any deviation is unacceptable unless is necessary to complete the features in the current sprint. • Daily scrum meetings are daily, means every day, same location, same hour. Rules
31. * • No Easy Road to Agile Cultural Change • Command and control/ Micro management -vs- Self management. • Transparency, no problems are swept under the carpet. • Transparency in planning. • Estimates and delivery dates are defined by the people doing the job. • Responding to change rather than managing to a plan. • The team makes decisions instead of being told what to do. Cultural Changes
32. * “Scrum exposes every inadequacy or dysfunction within an organization’s product and system development practices. The intention of Scrum is to make them transparent so the organization can fix them”
33. Kanban
34. Kanban
35. eXtreme Programming
36. eXtreme Programming
37. * • Source control, check-in policies • Continuous integration, deployment • Peer reviews • Pair Programming • Unit testing • Automated QA • Atomic Check-ins, Comments • Separate environments for Development, Testing and Production • Definition of done Best Practices at Nearsoft
38. * • Working on product maintenance rather than new functionality. • Working on the urgent rather than the important. • Poor or no communication. • Bug/Feature creep (out of control). • QA or other stakeholders not part of the team. • Write code without stories. • Delivery process is a problem or non-existent. • No learning from mistakes, repeating over and over. • Assigning tasks. • Imposing deadlines. Worst Practices
39. Planning Poker
40. Scrum & Kanban • Scrum Project Planning Session • Scrum Sprint Planning Session • Scrum Standup • Scrum Retrospective • Kanban Grooming Session
41. Planning Meeting The iteration or Sprint Planning meeting is for team members to plan and agree on the stories or backlog items they are confident they can complete during the sprint and identify the detailed tasks and tests for delivery and acceptance. Requirements: • Clear and prioritized backlog
42. Planning Poker • Planning Poker is a consensus-based estimating technique. • Planning poker is attributed to Grenning and is a fairly recent development (2002). • Planning Poker is widely used by Agile teams.
43. Participants • Participants in Planning Poker include all of the developers on the team. • Project Manager. • Product Owner, or someone on his/her behalf. Others may participate observers only: • QA, Designers, etc…
44. How to play?
45. Classic Set of Cards Source: Wikipedia
46. How to play? • Each estimator is given a deck of cards. • A moderator (typically the PM) who will not play, chairs the meeting. • The moderator reads the description of one task, a short overview will do. • The team is given an opportunity to clarify assumptions and risks. The product owner answers any questions that the estimators have.
47. Results? • Each estimator privately picks a card. Cards are not shown until each estimator has made a selection. • At that time, all cards are simultaneously turned over and shown so that all participants can see each estimate. • People with either high or low estimates are given a chance to justify their estimation. • Repeat until the estimators have reached a loose consensus.
48. Why do we love Planning Poker? • Discussions lead to accurate estimations. • Not just the opinion of the principals. • Greater understanding of work to be completed • Leverages collective knowledge and wisdom. • Implementation hints. • High level architecture and design discussion. • Ownership of estimate. • Favors teamwork.
49. Demo PlanningPoker for Hangouts
50. Story Points
51. Sets of Cards
52. Example of Story Points
53. Velocity: The sum of the estimates of delivered (i.e., accepted) features per iteration.
54. Recommendations
55. Recommendations • Only those who actually do the work are the ones that can vote. Please PM’s ;) • Don’t go into long discussions or into too much technical detail. • Use the “I need a break” and “question” cards. • Use a timer to limit the discussion. • Use Planning Poker for Hangouts in distributed teams. • Limit the total duration of your planning meetings.
56. "Planning is everything, Plans are nothing” -Dwight D. Eisenhower Thanks!