Achieving better requirements on Agile projects:User stories and beyond BHAWANA V. GUPTA, IBM email@example.com
Agenda AGILE USER• A quick peep into the ‘World of structured requirements’ STORIES• The Agile way of Requirements SEVEN• Common pitfalls when dealing with Agile Requirements HABITS• Adopt SEVEN habits to achieve better requirements 2
The World of Structured Requirements‘Big Requirements Up Front (BRUF)’ Approach Changes are not handled effectively Scope Assumption / guess work on requirements Over reliance on documentation Quality Why do organizations choose to workThe Waterfall Paradox: Scope and Time (or this way?Cost) are fixed, but in practice, all threeconstraints become fixed.... which leads uIron Triangle’.
Break the ‘Iron Triangle’Of the three critical factors – scope, cost, and time – vary at least oneCost is constrained Time is fixed Project costs are usually fixed Sprints and Iterations Resources are constrained by Releases and Milestones Brooks’ Law Quality Scope Scope = Value • The product backlog is the backbone for scope management • Not ‘all’ will be done • Prioritisation is key to delivering value 4
How can WE do that?
Consider an Agile Approach Requirements Requirements specs Code Tests Tests Code Prioritized Requirement ListDone SilosDoneDone Agile Team Collaborates with Customer One whole team
The Agile way of defining requirements Initial requirements are initially envisioned at a very high level . The goal of the requirements envisioning is to identify the high-level requirements as well as the scope of the release (what you think the system should do). Most agile teams are concerned only with the three innermost levels of the planning onion Mike Cohn (2008)7
And how is that done?User Stories Basis for the Requirements Bridges the gaps from business goals to implementation plans
User Stories: An Agile Approach to Requirements As a registered student, I want to view course detail so Card that I can create my schedule Conversation What information is needed to search for a course? What information is displayed? Confirmation Try it with a student with no ID Try it with a missing course title Stories are short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system Stories should be able to fit into a single iteration; if the size is larger, it should be grouped into smaller logical sections Epics will be used for the following purposes (to be created from business requirements) –Collection of related stories, to help organize the work –As placeholder for a functionality/group of stories where the work hasn’t been clarified
Where do User Stories fit in?Business perspective •Epics backlog Epics •Stakeholders goals Span Releases •Backlog constraintsSystem perspective •Features Features Fit in releasesUser perspective •Stories backlog •Backlog constraints User Stories Fit in iterations Implemented by TASKS Source: Dean Lefingwell10
Common pitfalls with Agile Requirements• Major challenges with attitude over new language o User stories, velocity, story points, epics, backlog..• Major challenges with requirements and requirements details o Is the context known? How much do we know about the dependencies links that are of contextual relevance. o How do you establish upfront business commitments? o How do we account for backlog items that do not fit user story paradigm? o Aside from user stories, what are ways to represent product needs? o Where are my business rules? o Where are my “quality of services” (NFR)? o Where do I track other constraints?• Major challenges with stories o User story Vs. system story User stories are just part of requirements o Finding epics and stories from process models? o Who is in charge of discovering stories?
Adopt SEVEN effective habitsHABIT #1• Establish Context and ScopeHABIT #2• Focus on Business ValueHABIT #3• PrioritizeHABIT #4• Elaborate requirements progressivelyHABIT #5• Collaborate, CommunicateHABIT #6• Focus on qualityHABIT #7• Manage
Adopt Habit #1: Establish Context and Scope Establish a shared vision that captures customers real needs Consider your organization scaling factors: i.e. distributed team Consider all work that needs to be done Defects, Change Requests, Review the work of other teams, and so on. All of this work needs to be taken into account when creating the backlog. Product Backlog Size As a customer I want to be … 5 As a customer I want to be … 3 As a administrator I want … 2 Rank Order User/System As a business planner I … 3 Stories Defect 1 ….. 8 As a administrator I want … 2 Product Change Request 1 5 Backlog As a customer I want to be … 1 Defects / Change Requests Change Request 2 8
Epics and StoriesA Product Backlog with context High Level Requirements Shows how stories fit together Shows which are completed Shows how we have ranked them Other Rankable ‘Requirements’ Showing Context in the Backlog Shows what isn’t done Shows Architecture concerns Shows were other things rank
Adopt Habit #2: Focus on business and user valuesExplore business value not only from User Stories but from other requirements Delivered business value is the only measure of success We must establish a shared vision that captures customers real needs Ranked Backlog: List of work items prioritized by importance or value to the business stakeholders, risk and dependencies And…..select the practices that add value……deliver iteratively….deliver something of value every iteration . Tips It does not matter what type a requirement is, functional or not, just that you do not forget to include it when prioritizing, estimating. In agile do not try to force requirements language on people Smart team should be aware of what add “value” to business and users. 15
Put Information in the right context Requirements Epics / Stories Functional Requirements Non Functional Requirements (NFR) which are: Cross-cutting Technical stories to capture NFR’s Pertinent to many functional requirements (user stories) Typically maintained outside of the work item list Acceptance Criteria Addressed throughout the entire project Often technical constraints on your solution Other functional requirements Acceptance Criteria Business rules Data requirements Others: Dependencies between teams Track dependencies using the stories paradigm
NFR Vs. Constraints• Using a check list to validate Qualities and the development of architectural aspects• When see a fit, use the story paradigm… Availability Story1 Story2 Maintainability Constraint - User Story A Portability AC for User Story B Safety Design Constraints Security Performance Usability Regulations Standards Common kind of Known constraints Non Functional requirements Tip Use a check list to discover constraints that will impact the project that is revisited every time the team is estimating, prioritizing…
Release and Sprint Backlogs with context
Adopt Habit #3: Prioritize Prioritize them, Size them using story points, Rank order them, by taking into account the NFR and constraints
Prioritize everythingbased on business value at the time Ranking by Business Value Defects vs New Development Sometimes Defects are higher ranked than new Stories Sometimes Defects can wait, and new Stories rule the day
Adopt Habit#4: Elaborate Requirements Progressively value value Growing details over time
Obtain "Just enough detail" when needed• Apply “Just barely enough” practice• Do some agile modeling (Model storming)• Defer detail until you have the best understanding you are going to have about what you really need• Apply these principles: o Evolutionary design o Good enough for the customer o Good enough for the “purpose” of the iteration.
Just enough detail, exactly when needed Backlog Release Sprint
Adopt Habit #5: Collaborate, CommunicateEmphasize verbal rather than written communicationCollaborate any time , anywhere any required!• Collaborate to build the backlog• Collaborate to build consensus on appropriate level of details required• Collaborate during your iteration planning• Collaborate at any time during your construction phase o Tasks and stories belong to the team o The team is anyone who can participates. o Work flows between team members.• Adopt a Business value focused collaboration: Do not supports a task culture (vs. value culture) where work isn’t collaborative
Adopt Habit #6: Focus on QualityAcceptance tests are your requirements specifications Why quality matters? • Quality is not an after thought in agile world • Quality is to make sure o the requirements are correct o They meet the stakeholders needs • Acceptance criteria drive the acceptance tests. • Acceptance tests, define what you will test, what you will not test o Acceptance tests define when story is done o Are artifacts of the conversations, not intended to be thorough • Acceptance tests drive (not replace) the real test code, drive (not replace) the test case development, etc. o Detailed test management as appropriate is still required25
Discovering acceptance criteria during conversation• Identify your Acceptance criteria from o your stories attributes o NFR that are not stories o Business rules that are not stories• Acceptance criteria are always required o What is required to make the story acceptable to the stakeholder? o Does the story deliver the value intended? o Does the solution solve the user’s problem? o Based on decisions made in story discussions that define how the story will work• Acceptance criteria are measurable and concrete• Acceptance criteria are specific• Acceptance criteria are unambiguous• Acceptance criteria are achievable
Quality and Validation built into the process
Adopt Habit #7: Manage • Use the Product Backlog as the single source of all planning activities. • Effectively scope and manage backlog and release / sprint plan. • ‘Manage’ NOT ‘Control’. • Do not undermine self-organization. • Involve the teams in determining their constitution. • Define effective “doneness” criteria. • Use Metrics and measurement capabilities to help the team track progress .
Visualize your workflowto provide transparency and visibility
To Summarize• Apply Agile principles and take them to heart o No more kicking requirements over the wall o No more big requirements documents o Become embedded in the team and the process• Become part of the full project lifecycle o Realise requirements is an ongoing process throughout project o Prepare to be a part of the team for longer time frame, through many iterations/sprints o Become embedded in the Quality aspect of the lifecycle• Embrace change! o Embrace the organisational change that comes with agile o Embrace constant change to the project scope/requirements/needs/priorities