The practical value of this presentation is to help business analysts to adapt to agile and use appropriate techniques to achieve better requirements. The key take aways; -Understand the difference between a traditional way of dealing with requirements and the agile way. -Describe core agile requirements practices -Understand challenges with agile requirements -Learn sty a high level the User story concepts and Describe where they fit in the life cycle -Understand how Acceptance tests extend User Stories -Understand the evolution of user stories and their and elaboration throughout the life cycle

1. Achieving better requirements
on Agile projects: User stories and beyond
CHERIFA MANSOURA
Agile Coach, Business Architect
ca.linkedin.com/in/linkedincherifamansoura
TEKsystems, Montreal
cherifa174@gmail.com

2. 2 2
Agenda
§ A quick peep into the ‘World of structured requirements’
§ The Agile way of Requirements
§ Common pitfalls when dealing with Agile Requirements
§ Adopt SEVEN habits to achieve better requirements
Here is Edward bear, coming downstairs now, bump, bump,
bump
on the back of his head…
It is as far as he knows, the only way of coming downstairs
But sometimes he feels that there really is another way……..
AA Milne, Winnie-ther-Pooh
AGILE
SEVEN
HABITS
USER
STORIES

3. 3
The World of Structured Requirements
‘Big Requirements Up Front (BRUF)’ Approach
§ Changes are not handled effectively
§ Assumption / guess work on requirements
§ Artifact-driven and Overreliance on
documentation
The Waterfall Paradox: Scope and Time (or
Cost) are fixed, but in practice, all three
constraints become fixed.
Waterfall seems simple to adopt
... which leads us to the ‘Iron Triangle’.
Why do organizations choose to work
this way? Quality
Scope

4. 4
Break the ‘Iron Triangle’ with Agile
4
Scope
Quality
Scope = Value
§ The product backlog is the backbone for scope management
§ Not ‘all’ will be done
§ Prioritisation is key to delivering value and mitigating risks earlier
Time is fixed
§ Sprints and Iterations
§ Releases and Milestones
Cost is constrained
§ Project costs are usually fixed
§ Resources are constrained by
Brooks’ Law
Of the three critical factors – scope, cost, and time – vary at least one

5. 5
How this can be done?

6. 6
Consider an Agile Approach and breaking down the barriers
Prioritized
Requirement List
TestsCode
Requirements
specs
Tests
Code
Requirements
One whole team
Silos
Agile Team Collaborates with
Customer
ü Done
ü Done
ü Done

7. 7
Agile Requirements: Strategies are changing
Practices are shifting into a leaner way
Continual customer involvement
§ Product owner represents the stakeholders
§ Active participation of the Stakeholders
Shared vision
§ Understand business needs
§ Focus on stakeholders goals
Requirements elicitations
§ Conversations, agile modeling, workshops
Requirements analysis
§ Performed “just in time”
Requirements documentation
§ User stories, storyboards, acceptance tests, agile
models
§ Is your documentation adding value? Test it
Ceremony, Formality
§ More relaxed approach

8. 8
And how is that done?
User Stories
§ Basis for the Requirements
§ Bridges the gaps from business goals to implementation plans

9. 9
User Stories: An Agile Approach to Requirements
Card
As an amazon customer, I want to view book details so
that I can decide to buy it
Conversation What information is needed to search for a book?
What information is displayed?
Confirmation Try it with author name
Try it with a title
Try it with key words
• 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)
– As placeholder for a functionality/group of stories where the work hasn’t been clarified

10. 10
Span Releases
Fit in releases
Fit in iterations
Where do User Stories fit in?
Business perspective
• Epics backlog
• Stakeholders goals
• Backlog constraints
System perspective
• Features
User perspective
• Stories backlog
• Backlog constraints
10
Source: Dean Lefingwell
TASKS
Epics
Features
User Stories
Implemented by

11. 11
Common pitfalls while dealing with Agile Requirements
§ Major challenges with attitude over new language
– User stories, velocity, story points, epics, backlog..
§ Major challenges with requirements and requirements details
– Is the context known? How much do we know about the dependencies links that are of
contextual relevance.
– How do you establish upfront business commitments?
– Are you in a contractual situation?
– How do we account for backlog items that do not fit
user story paradigm?
– Aside from user stories, what are ways to represent
product needs?
– Where are my business rules?
– Where are my “quality of services” (NFR)?
– Where do I track other constraints?
§ Major challenges with stories
– User story vs system story User stories are just part of
requirements
– Finding epics and stories from process models? Who is in charge?

12. 12
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
Adopt SEVEN effective habits

13. 13
Adopt Habit #1: Establish Context and Scope
Product
Backlog
User/System
Stories
Defects / Change
Requests
§ 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.
As a customer I want to be … 5
As a customer I want to be … 3
As a administrator I want … 2
As a business planner I … 3
Defect 1 ….. 8
As a administrator I want … 2
Change Request 1 5
As a customer I want to be … 1
Change Request 2 8
Product Backlog Size
RankOrder
Product
Backlog
Vision

14. 14
Put Information in the right context
§ Requirements
§ Functional Requirements
§ Non Functional Requirements (NFR) which are:
• Cross-cutting
• Pertinent to many functional requirements (user stories)
• Typically maintained outside of the work item list
• Addressed throughout the entire project
• Often technical constraints on your solution
§ Other functional requirements
§ Business rules
§ Data requirements
§ Others: Dependencies between teams
§ Track dependencies using the stories paradigm
§ Technical stories to
capture NFR’s
§ Acceptance Criteria
§ Acceptance Criteria
§ Epics / Stories

15. 15
NFR vs Constraints
§ Using a check list to validate Qualities and the development of architectural aspects
§ When see a fit, use the story paradigm…
Tip
§ Use a check list to discover constraints that will impact the project that is revisited every time the
team is estimating, prioritizing…
Availability
Maintainability
Portability
Safety
Security
Performance
Usability
Design Constraints
Regulations Standards
Common kind of
Non Functional requirements
Known constraints
ü Story1
ü Story2
ü Constraint - User Story A
ü AC for User Story B

16. 16 16
Adopt Habit #2: Focus on business and user values
Explore how to define 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.

17. 17
Adopt Habit #3: Prioritize
Only with a clear business
value, will the stakeholders be
able to adequately prioritize
the release content
Prioritize them,
Size them using story points,
Rank order them, by taking
into account the NFR and
constraints
See http://www.agilemodeling.com/essays/prioritizedRequirements.htm

18. 18
Adopt Habit#4: Elaborate Requirements Progressively
Growing details over time
value
value

19. 19
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:
– Evolutionary design
– Good enough for the customer
– Good enough for the “purpose” of the
iteration.
Source: Scott Ambler; agile modeling

20. 2020
Beyond Stories are details… but “Just enough details”
For each story selected, gather the details
§ During conversation: Discuss story, make sure
everyone understands
– Clarify the goal and business value
– Collaborate
– Flesh out details (Business rules,
constraints, ..NFR)
§ Define Acceptance criteria
§ Define the tasks required to complete the work
§ Review the tasks as a team if they were defined
separately
§ If the amount of time required to complete tasks
exceeds time available, drop a story or break a
story down, reassess

21. 21
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
– Tasks and stories belong to the team
– The team is anyone who can participates.
– 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

22. 2222
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
– the requirements are correct
– They meet the stakeholders needs
§ Acceptance criteria drive the acceptance tests.
§ Acceptance tests, define what you will test, what you will not test
– Acceptance tests define when story is done
– 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.
– Detailed test management as appropriate is still required

23. 23
Discovering your acceptance criteria during conversation
§ Identify your Acceptance criteria from
– your stories attributes
– NFR that are not stories
– Business rules that are not stories
§ Acceptance criteria are always required
– What is required to make the story acceptable to the stakeholder?
– Does the story deliver the value intended?
– Does the solution solve the user’s problem?
– 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

24. 24
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 .

25. 25
Visualize your workflow, to provide transparency and visibility

26. 26
What are the take aways?
§ Apply Agile principles and take them to heart
– No more kicking requirements over the wall
– No more big requirements documents
– Become embedded in the team and the process
§ Become part of the full project lifecycle
– Realise requirements is an ongoing process throughout project
– Prepare to be a part of the team for longer time frame, through
many iterations/sprints
– Become embedded in the Quality aspect of the lifecycle
§ Embrace change!
– Embrace the organisational change that comes with agile
– Embrace constant change to the project scope/requirements/
needs/priorities

27. 27
27
References

28. 28