Raspberry Pi 5: Challenges and Solutions in Bringing up an OpenGL/Vulkan Driv...
AT2012_Pune_UserStories_BhawanaGupta
1. Achieving better requirements on Agile projects:
User stories and beyond
BHAWANA V. GUPTA, IBM
bhawana.gupta@in.ibm.com
2. 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
3. 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 work
The Waterfall Paradox: Scope and Time (or
this way?
Cost) are fixed, but in practice, all three
constraints become fixed.
... which leads uIron Triangle’.
4. Break the ‘Iron Triangle’
Of the three critical factors – scope, cost, and time – vary at least one
Cost 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
6. Consider an Agile Approach
Requirements
Requirements
specs
Code Tests Tests
Code Prioritized
Requirement List
Done Silos
Done
Done
Agile Team Collaborates with
Customer
One whole team
7. 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
8. And how is that done?
User Stories
Basis for the Requirements
Bridges the gaps from business goals to implementation plans
9. 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
10. Where do User Stories fit in?
Business perspective
•Epics backlog Epics
•Stakeholders goals Span Releases
•Backlog constraints
System perspective
•Features
Features Fit in releases
User perspective
•Stories backlog
•Backlog constraints
User Stories Fit in iterations
Implemented by
TASKS
Source: Dean Lefingwell
10
11. 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?
12. Adopt SEVEN effective habits
HABIT #1
• Establish Context and Scope
HABIT #2
• Focus on Business Value
HABIT #3
• Prioritize
HABIT #4
• Elaborate requirements progressively
HABIT #5
• Collaborate, Communicate
HABIT #6
• Focus on quality
HABIT #7
• Manage
13. 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
14. Epics and Stories
A 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
15. Adopt Habit #2: Focus on business and user values
Explore 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
16. 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
17. 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…
19. Adopt Habit #3: Prioritize
Prioritize them,
Size them using story points,
Rank order them,
by taking into account the
NFR and constraints
20. Prioritize everything
based 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
22. 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.
24. Adopt Habit #5: Collaborate, Communicate
Emphasize verbal rather than written communication
Collaborate 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
25. Adopt Habit #6: Focus on Quality
Acceptance 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 required
25
26. 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
28. 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 .
31. 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