Sgin2013 scrum accompllished-whatandwhat not!- apo-introspects-angelineagarwal

523 views

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
523
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Sgin2013 scrum accompllished-whatandwhat not!- apo-introspects-angelineagarwal

  1. 1. Angeline Aggarwal, CSPO Product Owner, Tata Consultancy Services Scrum Gathering India Regional 2013 July, 2013 : +91 99201 37484 : angelinepp@gmail.com What and What NOT! - A PO Introspects
  2. 2. 2 A Product Owner is born! Developer for 7 years Working on RAD methodology; accustomed to quick turn-around times. Suddenly Agile – Alice in Wonderland! One-week sprints were being followed enterprise wide – Hit the ground running! In this presentation…… Scrum flow reviewed At each step identify  Common mistakes a beginner makes  How they impact the end result  How to avoid / become better
  3. 3. ENVISION1
  4. 4. 4Introspection by Angeline Aggarwal A vision must be detailed enough to provide clarity… Why have a vision?  Guides the team and describes the essence of the project  Provides clarity to the stakeholders that the team has understood what they have to do! Attributes of a good vision  Other Attributes  Stable  Clear  Appealing  Broad  Short  Pass the elevator test  Demystify the WHO, the WHAT, the WHY and the HOW  Who are our customers  What do they need  Why do they need  How we can meet the needs
  5. 5. 5Introspection by Angeline Aggarwal But “Vision” for my first project was woefully incomplete! Vision for the my first scrum project To make all finance system applications compliant with new firm wide change My Scorecard: Attributes Score What's the problem? Who is the stakeholder POOR Team does not know who to turn to, if we run into impediments and feedback What are the customer needs POOR Unclear: Left open-ended with a catch-all "ALL" systems compliant Why does the customer need it POOR Not identified: Team can't identify with the customers needs What is the target time-frame POOR Not stated: How do we figure out what resources/time are required and how much time will be required Stable POOR The client can go on making continuous changes Clear POOR Scope left unclear Short GOOD But its too short, doesn’t cover even the essentials Broad GOOD Its TOO broad and left open-ended Engaging POOR Only because it is short
  6. 6. 6Introspection by Angeline Aggarwal This is what the ‘Vision’ should have looked like Revised Vision Statement Description Problem/Opportunity Statement  Customer is implementing a new length of employee ids to cater to influx of new hires  All downstream applications may not support the increased length Potential Solution  Test critical applications  Identify issues  Fix issues to make the application compliant Scope of the project  To identify list critical applications which do not have an development team  Applications which are not to be decommissioned in the next one year Who is the stakeholder/Customer  Program managers (indentified people) for portfolio of applications Value to the customer  New hires would be able to use applications error free Timeline  6 months Success Criteria  Applications should support new length of person id While it is not short, it is crisp and contains all the relevant information
  7. 7. 7Introspection by Angeline Aggarwal What went wrong  No clarity on scope / interim changes  Not knowing who is involved and in what capacity  Not having asked the right questions Impact  Improper prioritization of the requirements/backlog  Slow the pace in removing impediments, getting approvals, requirement clarifications Doing it right…  Ask: The more you ask the more you understand. But ask the right questions  What is more critical  What needs will it address for the user  Share the vision with the entire team and make sure the entire team has the same understanding  Engage with the sponsor: With the right person at the right time will help in proper planning and removing most of your impediments in next steps ‘Vision’ - Recap
  8. 8. CREATE A BACKLOG2
  9. 9. 9Introspection by Angeline Aggarwal Step 2: Creating a backlog consisting of epics and stories  The product owner translates the vision into a backlog  Product backlog contains the following: o Themes/Epics/Stories, Technical work and defects. Attributes of a good Product Backlog  D E E P  Detailed Appropriately  Emergent  Estimated  Prioritized  Visible: Readily available to the team and stakeholders What is the backlog
  10. 10. 10Introspection by Angeline Aggarwal How I created my first backlog In my project:  Each application became an ‘Epic’  Disregarded the Iceberg: Aiming to break down all the ‘Epics’ into detailed ‘Stories’ to get to know the overall size of the project (Waterfall mindset) - Spent two sprints breaking down half the sprints before checking course  Two types of stories  Standard setup stories common for all applications  Application Specific Stories  Started implementation of set up stories for couple of applications and staffed with team  Project was set up in ‘Mingle’
  11. 11. 11Introspection by Angeline Aggarwal A backlog in disarray 0 1 2 3 4 5 6 7 8-10 11+ Set up Mingle Get Access App_1 to 10 App_1 Demo App_1 Story_1 and 2 App_2 Analyz e Code App_2 Confir m change s with User App_2 Code changes . . . App_2 – Identify Testing Strategy App_2 - Testing App_2 – Testing interfaces (Dependency came up) Get info App_1 to App 10 Staff Team App_1 and App_2 App_1 Analyze code App_2 Demo and Analyze Code [App_1 contin ued on track] Adhoc Develo pment work (Added subseq uently) . . . . . Adhoc Development work (Added subsequently) . . .
  12. 12. 12Introspection by Angeline Aggarwal Backlog: What was wrong and what was the impact  Incorrect Prioritization: Too much upfront effort adding details to ‘Epics’ to be taken up much later  Impact: Effort wasted and re-planning required, big picture missed due to ‘too many items’  Activity specific sprints: Application 2 was proceeding like a waterfall model within the agile framework  Impact: Idle time- Developer idle due to delay from user. No back up work planned  Interdependencies of applications overlooked:  Impact: Unforeseen delays due to dependencies on teams handling other application  Ineffective Planning: Should have identified testing strategy upfront  Impact: Emergency changes in release planning  Adhoc development work added to backlog – Team ‘Vision’ was compromised. Cascaded into multiple change requests and additional work  Impact: Huge delay. Initial user estimate of 2 months took 3 months despite overworked team  Neglect backlog Grooming: Specific time not allocated for backlog grooming  Impact: Could not eliminate unwanted items prior to sprint – backlog not ready for next sprint – resulting in confusion for the team Overall impact:  Non shippable deliverables per sprint  No sign off from the customer  Overall release getting delayed by 3 months
  13. 13. 13Introspection by Angeline Aggarwal Backlog: Lessons learnt  Prioritization  Take up application with most dependencies initially  Progressively refine – Impossible to think of everything upfront  Add details Just-In-Time, not weeks in advance because things change as new information emerges  Helps avoid too many backlog items  Stick to the vision:  Any adhoc requests not in line with project vision should be treated like a separate project – with its own backlog and stories  Backlog Grooming  Would have set aside Time-boxed period for the entire team to focus on cleaning up the backlog
  14. 14. ESTIMATE3
  15. 15. 15Introspection by Angeline Aggarwal Estimation 101 The process of quantifying the effort required in story points or ideal days involved in implementing the Product Backlog with the resources available What is Estimation The WHEN, WHO And HOW of Estimation  The When:  Before the first sprint  During the first 2 sprints  On going  Who: Product Owner + Scrum Master + Team  The How  Story points vs. ideal days  Planning poker End Result  Sized Stories  Results in backlog refinement
  16. 16. 16Introspection by Angeline Aggarwal What were the mistakes Impact How to avoid them Playing the task master: • Product owner drives estimate based on deadline of the project • Team estimated 3 weeks I pushed for 2. It finally took 3 weeks • OR Team compromises on Quality Estimate should be Honest not influenced: • Developer should give the estimate not the product owner • Scrum master to facilitate Equating story points to days: • Each story is considered individually rather than a collection to relative estimate • Failed to see big picture • Overall deadline slippages •Play the poker - Its fun! Trying to estimate the inestimable! • Stories are too complex or too many unknowns/dependencies to estimate • Radically different estimates from team members due to different interpretations • Extended planning duration • Stop and think and break down further lUnclear Scale: lTeam not clear on the scale being used • Use a scale which all team members identify with • Identify smallest and largest at 2 points and 20 points respectively Chasing Velocity: Adjusting estimate to meet forecasted velocity • Slippages across sprint deadlines • Over-worked team – unsustainable in the long run • Velocity gets derived from the estimates and not the other way around Common pitfalls and how to avoid them
  17. 17. 17Introspection by Angeline Aggarwal POs - do not influence the team
  18. 18. USER STORIES EXAMPLES4
  19. 19. 19Introspection by Angeline Aggarwal Backlog consists of multiple USER stories  Defining the deliverables from a users perspective aligns with goal of the product  Format: As a <USER>, I want <SOMETHING>, so that <SOME VALUE> o For Technical stories, user is replaced by the module Define from a “USERS” perspective Attributes of a good Story  I N V E S T  Independent  Negotiable  Valuable  Estimable  Small  Testable  Should define the WHO, WHAT and WHY  Story should contain acceptable criteria (for validation) - Sufficient to define the boundaries of the story
  20. 20. 20Introspection by Angeline Aggarwal Its time to write a story: User Story 1 User Story: Add a share activity section to the share activity report to display share transactions for a user Acceptance criteria: Display share activity information in the following columns, no of shares, date, activity (Buy or sell), quantity, value per share and total amount User Story: As a user, I want to see the share activity details, for the selected person for the current financial year, so that I may view the details of the share transacted by that user and compute share balance Acceptance criteria: Display share sale and share purchase in separate rows with the following information, no of shares, date, activity (Buy or sell), quantity, value per share and total amount in a user defined format Should have been
  21. 21. 21Introspection by Angeline Aggarwal What were the mistakes Impact How to avoid mistakes The “WHY” is missing Story defined from a developers perspective of what needs to be done, not the why Impact: If we knew what we wanted to use the report for, we could have added additional data useful for user (like total gain in the period, etc) Could have suggested displays with additional data would could have been meaningful to the user Potential Additional revenue lost? Ask more questions with the stakeholder and constantly engage The WHAT not completely defined Report pertains to which year – what test data to retrieve NOT testable. Boundary condition missed out. Involve the team in story writing Not negotiable User wanted a different format for a boundary condition (shares bought and sold on the same date in separate columns) Could not be completed in simple sprint. Code had to be re-worked. Few person days additional required Describe by examples User could have pointed what he wanted Analysis of User Story 1
  22. 22. 22Introspection by Angeline Aggarwal Story..continued..: User Story 2 User Story: As a user, I want to run the report X for multiple employees in a given date range Acceptance criteria:  Report should accept multiple employee numbers in a comma or space separated string  User should be able to enter start and end date User Story: As a user, I want to run the report X for multiple employees in a given date range so as to be able to generate a batch of reports of all employees under a partner at one time Acceptance criteria:  Report should accept multiple employee numbers with a minimum of 750 in a comma or space separated string  User should be able to enter start and end date  The entire report should be generated in a maximum of 30 seconds Should have been
  23. 23. 23Introspection by Angeline Aggarwal What were the mistakes Impact How to avoid mistakes The “WHY” is missing Lead to unclear boundary condition below Focus on discussion rather than documentation: Ask more questions and constantly engage with the user ilities and UI constraints Boundary condition not defined: User wanted to run report for a minimum of 750 users at one go Performance tuning (optimization) was not done Architecture reworked for optimized performance Missing definition of done How long should the report generation take was not listed The entire report could not be done in 30 secs as required by the user, had to increased up to 2 mins Analysis of User Story 2 Is it possible to write a complete story upfront and ready for a sprint - NO
  24. 24. ALL ABOUT THE SPRINT5
  25. 25. 25Introspection by Angeline Aggarwal Sprint away!  A time-boxed period during which the scrum team works to build a potentially shippable increment to the product  Both incremental and iterative at the same time  Iterative - Planning + Execution + Review  End result: Potentially shippable increment to the project / product Deliver at end of each sprint: Allows to inspect and seek constructive feedback
  26. 26. SPRINT PLANNING6
  27. 27. 27Introspection by Angeline Aggarwal What is Sprint Planning  Entire team (Product Owner, Scrum Master, Developers, etc) participate in the Sprint planning meeting to discuss the following  Sprint goals  Selection of sprint backlog for the next sprint (Backlog items that the team commits to and the tasks they are broken down into)  Typical effort of two-four hours per sprint What happens during Sprint Planning Outcome of Sprint Planning  Defining what the team will achieve in the next sprint  Shippable increments  Behind-the-scenes features  Just something valuable  Further break down stories based on new details  Emergent requirements
  28. 28. 28Introspection by Angeline Aggarwal Sprint Planning Case Study Top Story Priorities Stories Points App_2 Testing (Modules 01 to 10) 3 App_2 Testing (Modules 11 to 20) 3 App_2 Testing (Modules 21 to 30) 3 Test App_2 Interface 1 5 Test App_2 Interface 2 5 Capital Tax Report (became a 20 pointer subsequently) 8 App_3 Analyze Code Base 3 App_3 Get Access to Dev Env. 2 App2_Analyze Back end 3 App3_Analyze Import Module 3 App3_Upload 2 App3_Sumbit 3 Chasing too many points per sprint Interface modules should have been prioritized over • Story too big to be taken up and therefore broken down • Task based break down into : Analyze the requirement, etc Detailed plan for all the activities put in place much in advance
  29. 29. 29Introspection by Angeline Aggarwal Sprint Planning Mistakes Impact How to avoid mistakes Lacking the big Picture: • Selecting stories with a short term goal in mind • In-correct prioritization and thereby selection of sprint • Start with a prioritized backlog • Always first take stories which have maximum interdependency Waterfall in Agile • Planning activity specific sprints rather than holistic development of an increment • No user specific deliverable • Risk of spending too much time for one activity which doesn’t get validated • AVOID the temptation and ALWAYS deliver at-least a testable increment Chasing Velocity • Over-committing or selecting stories that are too large for the sprint Planning for overwork “Need to complete at least 14 story points to maintain our velocity” • Overworked team • Compromise on testing and quality OR • Under deliver in next sprint • Plan based on what can be completed end to end • Selecting the right mix of stories – not all large, not all small • Achievement is not in terms of velocity – velocity should result from doing scrum right Planning for a better finish
  30. 30. 30Introspection by Angeline Aggarwal Sprint Planning Mistakes Impact How to avoid mistakes Scheduling issues • PO/ Team member is not available for the meeting • Team members don’t understand the sprint goals • Be flexible with scheduling • Make the planning meeting compulsory to all lPlanning too much into the future • Little room for progressive adjustments, • Leads to effort waste • Product Owners! Know your backlog • Plan at the optimal time – one or two sprints in advance Starting the new sprint with planning • Should be done 2 days before next sprint starts • Result in idle team • Lead time to get At least 5-10% of team time should be reserved for planning for the next sprint Ignoring Team Ability / Availability • Leads to over committing and under-delivering • Avoid assigning story to individuals, assign story to a team / sub team • Opt for pair programming where-ever critical • Product owner should be aware of team absences and take that into account Think holistically – don’t lose track of the overall vision
  31. 31. SPRINT EXECUTION6
  32. 32. 32Introspection by Angeline Aggarwal Are we getting there? Can you see the goal?  Team works on the backlog items committed for the sprint  Mode of operation:  Time-boxed daily scrum  Task boards  Impediments list  Changes in boundary conditions – decide on whether to terminate the sprint
  33. 33. 33Introspection by Angeline Aggarwal Sprint Execution Mistakes Impact How to avoid mistakes No daily scrum • Inconsistent meeting times • Skipped meetings • Difficult to understand team progress • Individual follow up with team members – waste of time. • Team unaware of each others work and possible impact to their story • Disciplined daily scrum • Fixed meeting time and place Lack of enthusiasm • Team not fully involved • Meetings from their desk / simultaneously doing other work • Loose an opportunity to see overall progress, give and receive inputs • Just focused on status updates • Daily Stand-up done right! • Time-boxed no lengthy discussions • Accounting for time during DSM rather than goals and achievements • Developer may have spent a day on the story but achieved nothing in terms of value • Updates should be in terms of what was done and not how much time was spent on it Sprinting away from the goal and how to avoid it
  34. 34. 34Introspection by Angeline Aggarwal Sprint Execution Mistakes Impact How to avoid mistakes No mid sprint checks • Items left for implementing at the end – not mid-sprint checks • Compromised on scope and quality • Maintain Sprint Burn down chart • Not a time for troubleshooting • Reduce wasteful effort – automate where possible • Don’t leave testing for the end – it generally gets skipped • Changing the sprint goal/sprint backlog during the sprint • Hampers the team’s focus and rhythm • Leads to hasty and unplanned activity • Avoid changes to the sprint goal – what to do if the priority of backlog suddenly changes? lImpediments • Not raising / handling impediments • Delays • wasted effort • Slippages • PO should follow up / force / beg for team to come up with impediments • Make the team comfortable to escalate issues Sprinting away from the goal and how to avoid it
  35. 35. REVIEWS AND RESTROSPECTIVES 6
  36. 36. 36Introspection by Angeline Aggarwal A great finish! – Reviews and Retrospectives Objectives of the Sprint Review  1 hour per sprint: Set aside to reflect on the sprint gone by  Start, Stop, Change, Continue  Setup and continually improve best practices  No retrospective  A missed opportunity to learn  Repeat the same mistakes  Keep it informal  10-15 mins per Sprint to Inspect and Adapt  Highlight team goals and achievements  Assess the achievements against the sprint goal and not just completion of backlog  A natural end to the sprint, not a distraction requiring preparation time Retrospective: Learn from the past
  37. 37. 37Introspection by Angeline Aggarwal Maintaining a sustainable pace of development Pace yourself like a marathon runner; Get a head start, go steady in between & Towards the end, give it your all  Start Small but think Big – never forget the big picture  Use same length sprints - helps planning and the team works with Rhythm  Focus on delivery – Definition of done – complete story  Continuous improvement  Don’t bank on overtime – it cannot be sustained  Refine the plan – adjust to accommodate changes in scope, time  Never compromise on quality  Maintain agile discipline
  38. 38. APPENDIX6
  39. 39. 39Introspection by Angeline Aggarwal References  http://agile.dzone.com/news/retrospect-about-sprint  http://www.slideshare.net/Conscires/sprint-execution-standup-taskboard-etc  http://www.slideshare.net/romanpichler/product-backlog-tips-and-tricks  http://www.slideshare.net/dhaval.r.panchal/keeping-product-backlog-healthy  http://agilepainrelief.com/notesfromatooluser/2012/06/scrummaster-tales-learning-how- to-estimate.html  http://colearningbe.wordpress.com/2013/04/01/most-common-mistakes-in-scrum- ceremonies-27-estimating-stories/  http://scrummethodology.com/scrum-effort-estimation-and-story-points/ Websites Book  ‘Succeeding with Agile’ by Mike Cohn

×