Cheapest User Stories - The Achilles Heel of Agile
•Download as PPSX, PDF•
0 likes•139 views
A weak implementation of an Agile methodology could have many consequences, one of which is cheap user stories. Poor collaboration, misplaced ownership and using the wrong parameters to size a story are some of the key catalysts.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Cheapest User Stories - The Achilles Heel of Agile
Similar to Cheapest User Stories - The Achilles Heel of Agile (20)
Recently uploaded
Recently uploaded (20)
Cheapest User Stories - The Achilles Heel of Agile
- 1. ANTON OOSTHUIZEN Cheapest User Stories – The Achilles Heel of Agile
- 2. Biography • Certified PMI-PMP, PMI-PBA and AvMP • Over 2 decades experience in PM and BA professions • Diverse cultural background having worked on almost every continent • Consulting, systems integration and software development projects at medium to large corporates • Landscapes covered include finance, insurance, IT, aviation
- 3. Agenda • Agile primer • What is a cheap user story? • Why does it exist? • Case study • Results of cheap user stories • How do we avoid it • Key Takeaways • Q&A
- 4. It’s True
- 6. Agile Manifesto • Individuals and interactions rather than processes and tools • Not a ‘do as you are told’ environment • Working software rather than comprehensive documentation • Frequent demonstration of working software is best to communicate understanding of requirements • Customer collaboration rather than contract negotiation • Constant feedback loop • Responsive to change rather than following a plan • Allows for adjusting solution
- 7. Agile Scrum Process Requirements Product Backlog Sprint Planning Sprint Execution Release Sprint Backlog
- 8. Cheap User Story – What is it? • A cheap user story is NOT a weakness of the Agile methodology, or scrum framework, but rather of a bad implementation thereof. • A user story is MADE cheap when a solution is selected taking only story points into consideration • Results in a solution that satisfies the requirements within the acceptable quality parameters but at the lowest possible grade, “Just Barely Good Enough" (JBGE)
- 9. Why does it exist? • Misplaced Ownership – Product Manager is NOT Business Owner • Healthy disregard for Agile Manifesto point #4 • Sprint DO NOT result in release iteration by default • More likely to occur in supplier project driven virtual team • ‘Absent’ business owner • Time zone difference • Not Agile ‘enabled’ organization
- 10. Case Study Background Stakeholders use a system in a high stress, fast paced operational environment. Quick repetitive actions are often required. End users are computer literate and are familiar with normal Windows navigation standards. Users are categorized as external and internal. External users access the system using a web thin client while internal users access the system via a thick Windows client. The functionality is required by internal users and is core to the operational processes of the organization and the industry as a whole.
- 11. Case Study User Story As an operator I need to import code share information from a file so that it can be associated with the primary record in the operational system. Acceptance Criteria • When I select the file the system should verify the content and raise an alert for any rule violation. • When an alert is raised it must be possible to correct the error and continue.
- 12. Case Study Solution An import function is implemented in the web frontend. It does not have any means of resubmitting and any validation alerts needs to be resolved before the import process starts again. The controls used in the windows application are different to those used in the web frontend. Result The users are required to use two different application views to complete their task, adding additional cycles to the process. Core functionality is unbundled.
- 13. Case Study Background Stakeholders use a system in a high stress, fast paced operational environment. Quick repetitive actions are often required. End users are computer literate and are familiar with normal Windows navigation standards. Users are categorized as external and internal. External users access the system using a web thin client while internal users access via a thick Windows client. The functionality is required by internal users and is core to the operational processes of the department. Quick repetitive actions familiar with normal Windows navigation required by internal users core
- 14. Key Concepts • Quality vs Grade • Quality = Defects ratio within required scope • Grade = Value added by solution • Work Arounds • NOT a solution • Should only exist as temporary measure in extreme cases • Increase technical debt • Unbundling • Core functionality should NEVER be unbundled • Potential to lower grade
- 15. Results of cheap user stories • Low Grade • Over Engineered • Work Arounds • Unbundling • Inconsistency • Loss of Control • Rework • Technical Debt Death Spiral
- 16. How do we avoid it? 1. The obvious one – Proper implementation of Agile • Collaboration – Right Data, Right Stakeholders, Right Time • Review 2. Strong BA Mandate 3. Clear Acceptance Criteria 4. Consider Big Picture 5. Focus on Grade, not Quality 6. Never unbundle because it is easier 7. Not all companies or projects are Agile ready, DO NOT force it!
- 17. Psychotherapist
- 18. Remember This • Cheap User Stories are NOT an Agile weakness, it is a symptom of a badly managed environment. • Primary cause – No business representation, no collaboration. • Any user story can be made cheap by selecting a solution with the least amount of story points by default. • Product manager is NOT the business owner. • Supplier project driven, virtual teams are at a higher risk. • Even badly written user stories does not have to be cheap.
- 19. What did we learn QUESTIONS ANY
Editor's Notes
- I’ll talk to you from the receiving side i.e. receive low grade solutions because user stories were made cheap.
- 15 Agile principles in manifesto summed up by these 4 statements Team members must be self driven, identify issues and better solutions Working software provides the means to demonstrate to stakeholders and adjust if required Customer collaboration is vital but key question to be asked – WHO IS THE CUSTOMER? In a virtual environment the BA steps into the customer shoes Must be responsive to change i.e. if it is found that the solution is wrong it must be adjusted. Time constraints should not highest priority Agile scrum is not perfect, nor are the results that comes from it
- CUN previous and now
- Even the best written user story can be made cheap if the Agile processes are not in place and functioning properly Take path of least resistance, reuse even if it is not fit for purpose. What is already in place, what will be easier/quicker, what will be cheaper User story principle of describing only the problem, not the solution is the perfect catalyst for a cheap user story, in the absence of business. JBGE or Sufficient must be seen in context of value not quality.
- How do we end up with solutions that do not add value? No that many reasons and none are complex The BA role is that of business representative Business (BA) dictates functional solution Collaboration is a key corner stone of Agile Feedback loop becomes more important with virtual teams. Sprint release does NOT by default mean an acceptable release Project driven organizations with virtual team have all the right ingredients ScrumAlliance 2015 state of scrum report (5000 people, 108 countries, 14 industries)- 33% distributed, 63% combine scrum & waterfall ME / AFR lowest success rate
- The background for any requirement provided the big picture How can we invest now so that we can gain later? Why should we select a particular option
- Not all user stories are perfect and an inherent risk is that they are high level leaving room for discussion. This is where collaboration becomes the glue that sticks everything together
- While the solution technically satisfies the requirement it does so by interpreting the cheapest option. So the quality might be good but the grade is low. It results in additional work for the end user and actually degraded the process efficiency.
- Oversight that resulted in a bad solution would have been raised had proper collaboration and ownership been in place.
- Before we look at the results of cheap user stories lets define 3 key concepts that is often not understood: If quality is delivered when scope is delivered without defects. Grade defines efficiency, how well the solution address the problem i.e. Value. Quality defined by scope, Grade defined by stakeholder group. Work arounds are NOT solutions, it is a temporary measure that should not exist except in extreme cases Core functionality should NEVER be unbundled as it will lower the grade.
- What are the expected or most common results a cheap user story is likely to produce? Grade <> Quality More complex solution than is needed Try to implement a ‘solution’ using existing functionality Find the easiest place to do it Inconsistent behaviour across systems/applications/modules Ignoring checks and balances that might be required means the user do not have the desired level of control over the process Unsatisfied end user result in rework Technical debt dead spiral – THAT IS IF IT IS ACCEPTED THAT THE SOLUTION WAS A SHORT CUT
- How do we avoid, or at least mitigate the occurrence of cheap user stories? Proper Implementation Collaboration does not mean sharing with just anybody, if the correct stakeholders are not involved it means nothing There must always be place for review Position of BA must be clear and supported by the structure Always include clear acceptance criteria Always consider big picture Focus on delivering value within the scope. Quality will take care of itself Customer collaboration rather than contract negotiation – Not always possible!
- Key Takeaways from session