* Team velocity is 24 story points per iteration * Total backlog size is 256 story points * To calculate the number of iterations: - Total backlog size / Team velocity - 256 / 24 = 10.67 iterations (round up to 11 iterations) * Adding a 35% buffer to the backlog size: - Backlog size * (1 + Buffer percentage) - 256 * (1 + 0.35) = 345.6 story points * With the buffered backlog size: - Buffered backlog size / Team velocity - 345.6 / 24 = 14.4 iterations (round up to 15 iterations) Therefore, the number of iterations without buffer is 11 and with 35%

1. Backlog
Management &
Discovery

2. What is Agile?
• Agile is an umbrella term which has lot of approaches that enables us with growth mindset
and creating a culture where we respond to change over reacting
• Change is constant
• It is inversely proportional to inertia
• It helps us in shortening the feedback loop
• Intent is to fail or succeed faster
• Power of just-enough
• Progressive elaboration

3. Traditional Approach
CONCEPTION
INITIATION
ANALYSIS
DESIGN
CONSTRUCTIO
N
TESTING
DEPLOYMENT

4. Traditional Approach

5. Just-enough Mindset
• Let’s learn ‘bite of a burger’ concept ☺
• What happens when you take the first bite?
• We need to learn on how to limit our expectation and find out a
way to create minimum outcome which can create maximum
impact so as to fail faster by shortening the feedback loop

6. Project Progress in SCRUM
Project Start Project End
Sprint Sprint Sprint Sprint Sprint Sprint
“Definition of Done” is the key

7. Example: Online Shopping Experience
AUTHENTICATE

8. Mapping different Phases in Sprints
Release planning
Gate – Release1
Requirement
Approval Gate –
Release 2
Requirement
Approval Gate –
Release 1
Release planning
Gate – Release 2
Gate – XXX Gate YYY
Requirement Phase
Elaboration phase
Assessment Phase
Pre-Construction, Construction &
Validation phase
Post validation phase
US 7.4
Product Epic 8
US 7.5
Product Epic
1
Product Epic
2
Product Epic 1
US 1.1
US 1.2
Product Epic 3
Product Epic
7
Product Epic
8
Product Epic
7
Product Epic 7
US 8.2
US 8.3
US 3.3
Product Epic 8
Product Epic
3
Product Epic
4
Product Epic
5
Product Epic 6
Product Epic
9
Product Epic
10
Product Epic 3
Product Epic 4
Product Epic
11
Product Epic
12
US 4.1
US 4.2
US 3.1
US 3.2
Product Epic
13
Product Epic
14
Product Epic 2
Product Epic
11
US 3.4
US 3.5
Product Epic 6
US 7.1
US 7.2
US 7.3
US 8.1
Product Epic 6
US 6.1
US 6.2
Product Epic 1
1 2
7 8 6 3 4 5

9. An Umbrella of Approaches & its Practices
An approach
where typically
requirements &
solutions evolve
through
collaboration
of cross functional
teams.
Agile is NOT a
standard….
It’s collection of
practices which are
• Upheld by Values
• Guided by
Principles
• People Centric
• Self Organizing
• Value Driven
• Collaborative
• Servant Leadership
An umbrella term
for several
iterative and
incremental
software
development
methodologies.

10. Planning &
Backlog Mgmt
• Planning for a Release
Increment
• Discovery Session
• Story Mapping
• Personas, user stories, epics,
themes
• Estimation
• Release Planning

11. Planning in Agile

12. Bringing it all together

13. What we want?

14. Let’s start with DISCOVERY SESSION

15. Let’s start with DISCOVERY SESSION
Collect the
Ideas
Goal setting Persona Mapping User journey Story Mapping
MVP
identification
Now - Next - Later
Story writing Writing Epics
Writing User
stories & Tasks
Prioritization Identifying
Themes
Value & Risk MoSCoW ROI
Differentiator,
Spoiler, Table
Taker,
Organizational
cost
Estimation Scope, Cost &
Time
Story point
estimation
Base story
definition
Dependencies &
Risks
Timeline View
Sprint Zero
expectations

16. Goal Setting & Persona Journey

17. Goal Setting & Persona Journey

18. Story Map – Collaborate to create

19. Walking Skeleton

20. At your workspace

21. Story Map Example

22. Story Writing Session

23. Start with EPICS
● Epics are big, coarse-grained user stories. Starting with epics allows you to sketch the product
functionality without committing to the details.
● This is particularly helpful for new products and new features: It allows you to capture the rough
scope, and it buys you time to learn more about the users and how to best meet their needs.
● It also reduces the time and effort required to integrate new insights. If you have lots of detailed
stories, then it’s often tricky and time-consuming to relate any feedback to the right stories.

24. Decompose your Stories until they are Ready
Break epics into smaller, detailed stories until they are ready: clear, feasible, and testable. Everyone
should have a shared understanding of the story’s meaning; the story should not be too big, and there
has to be an effective way to determine if the story is done.
As one decomposes epics into smaller stories, Acceptance criteria complement the story’s narrative: They
allow to describe the conditions that have to be fulfilled so that the story is done.
The criteria enrich the story and make it more precise and testable, and they ensures that the story can be
demoed or released to the users and the other stakeholders. As a rule of thumb, use three to five criteria for
detailed stories.
Tests - The goal is to convey additional information about the story so that the developers will know when
they are done.

25. User Persona Creation
What is a User Persona?
∙ A Typical user of the system
∙ Start with provisional personas – using market insights, direct observation and problem
interviews
∙ Choose a Primary persona – the character you design and build the system for
∙ Test your personas – by building prototypes, product increments, MVPs
∙ Connect Personas and User stories – the primary persona should be the protagonist in the
user stories
∙ Visualize your personas
∙ Personas may not be necessary for all situations

26. Writing Requirements Effectively – User Stories
∙ User Stories are a short, plain-language description of the features, in terms
of customer value
∙ User Stories are centered around the customer and what they need to do
∙ They are structurally simple and provide a great placeholder for a
conversation
∙ They can be written at various levels of granularity and are easy to
progressively refine

27. User Stories - Card
● Acceptance
Criteria
● •
•
• Notes
● •
•
•
•
…
…
Back of the
Card
“As a user, I want to pay for items in my shopping cart using a credit card, so that I
can have them shipped to me”

28. User Stories - Conversation
● The card only covers the most basic information
● The next level of detail comes in conversations between the Product
Owner and the Team
● The conversations take place
• At project start, during story-writing sessions
• During the Backlog Refinement Meeting
• During the Sprint Planning Meeting
• During the Sprint

29. User Stories - Confirmation
● Accepts Visa, MC, AmEx and rejects other types of card
• Rejects invalid card number or expired card
• Accepts different dollar amounts
• Rejects amount higher than the card limit

30. Example : Travel Reservation System
As a user,
I can reserve a hotel
room.
As a
vacation
planner, I
can see
photos of
the hotel
As a frequent flyer, I
want to rebook a past
trip so that I save time
booking trips I take often
As a user, I
can cancel a
reservation

31. SPLITTING OF STORIES

32. Create Incrementally i.e. MVP

33. How to split?

34. It’s a funnel

35. Splitting Stories
Epics typically fall into following two categories:
The compound story
• It comprises of multiple shorter stories
• Example: A customer can plan a vacation (in a travel reservation system)
The complex story
• A story which is inherently large and cannot easily be disaggregated. It is called complex
because of uncertainty associated with it.
• In such cases split it into two stories: Investigative and development
• It is recommended to define a Spike around the investigative story.

36. At times it may become necessary for us to split the user stories into smaller stories:
• When it is difficult to fit a user story in a single iteration
• When there is not adequate time to fit the story in the current iteration, though it may be
small
• When there are operational requirements (like performance or any other non functional
specification)
• Split stories based on CRUD operations
• When the story is too big even to estimate
• Do not try and split stories into tasks / activities
When to Split User Stories

37. I Independent : Dependencies between stories make planning, prioritization, and estimation much
more difficult.
N Negotiable: A user story is negotiable
V Valuable: Each story has to be of value to the customer (either the user or the purchaser).
E Estimate-able: The developers need to be able to estimate (at a ballpark even) a user story to allow
prioritization and planning of the story.
S Small: A good story should be small in effort, typically representing no more, than 2-3 person weeks
of effort.
T Testable: A story needs to be testable for the "Confirmation" to take place.
How to Evaluate a Good Story INVEST

38. How to Slice?

39. ● Workflow Steps
● Business Rule Variations
● Major Effort
● Simple/Complex
● Variations in Data
● Data Methods
● Defer System Qualities
● Operations
● Use Case Scenarios
● Break Out a Spike
Splitting User Stories : Typical Attributes

40. Splitting User Stories by Operational Boundaries
• As a marketing representative I want to manage the online catalogue
so I can ensure our customers can purchase our products.
– As a marketing rep I want to create an item in the catalog so I can ensure our
customers can see and purchase our new products.
– As a marketing rep I want to read the list of items in the online catalog so I can
ensure our customers can see our current product list.
– As a marketing rep I want to update items in the online catalog so I can ensure
our customers have the most up to date info. on our products.
– As a marketing rep I want to delete items from the online catalog so I can ensure
our customers do not see or order discontinued items.

41. Splitting User Stories by Data Boundaries
• As a Financial Analyst I want to enter
balance sheet data so I can maintain
year wise financial information.
– As a Financial Analyst I want to enter
Summary balance sheet data so I can get
consolidated information.
– As a Financial Analyst I want to enter
Categorized balance sheet data so I can
view data in various categories .
– As a Financial Analyst I want to enter
Detailed Asset information so I can see
the breakup of asset information.
Splitting by Priorities.
•As a user I want to login so I can work
with my account data.
– As a user I want to have unlimited login
attempts so I can work with my account
data.
– As a user I want to be denied access
after 3 failed login attempts so my
account information is protected.
– As a user I want to receive emails when
access is denied to my account so I’m
aware of attempts being made to access
my account.

42. Identify specific steps that a user takes to accomplish a workflow, then implement the
workflow in increments.
As a utility, I want to
update and publish
pricing programs to
my customer...
...I can publish pricing programs
to the customer’s In-Home
Display
❖ ...I can send a message to the
customer’s web portal
❖ ...I can publish the pricing table
to a customer’s smart thermostat
Splitting User Stories by Workflow Steps

43. Business rule variations often provide a straightforward splitting scheme
As a utility, I can sort customers by
different demographics...
...sort by zip code
...sort by home demographics
..sort by energy consumption
Splitting User Stories by Business Rule Variations

44. Split by type of operation example: Create Read Update Delete (CRUD)…
As a user, I can
manage my account...
• ...I can sign up for an account.
• ...I can edit my account settings.
• ...I can cancel my account.
• …I can add more devices to my account
Splitting User Stories by Operations

45. If use cases are used to represent complex interaction, the story can be split via the
individual scenarios
As a user, I can enroll
in the energy savings program
through a retail distributor ...
• Use Case/Story #1 (happy path): Notify
utility that consumer has equipment
• Use Case/Story #2: Utility provisions
equipment and data, notifies consumer
• Use Case/Story #3 (alternate scenario):
Handle data validation errors
Splitting User Stories by Use Case Scenarios

46. What if the base use case is too big?
Use the heuristics in the graphic below
Techniques for slicing

47. In some cases, a story may be hard to estimate may be too
large or overly complex
or perhaps the implementation is poorly understood
In that case, build a technical or functional spike to figure it
out;
then split the stories based on that result.
Split – If All Else Fails, Break out a Spike
Technical
Spi
ke
Functional
Spik
e

48. Epic & User Stories
Story Writing Session
Epic Name Story Id As a I want So that Acceptance
Criteria
Assumptions
A A.1
A A.2
A A.3
A A.4
B B.1
B B.2
B B.3

49. Story Prioritization – MoSCoW Model
MoSCoW is a prioritization method and assists teams to organize storycards according
to the value from the customers perspective.
The story cards are organized into four categories:
M | Must have this attribute or feature; a non-negotiable
S | Should have this attribute or feature; should be included if possible
C | Could have this attribute or feature; less critical, “nice to have”
W | Won’t have; least critical, lowest value or ‘would like to have in the future’ MuSCoW
Technique

50. Story Prioritization – Value Driven
Do firstAvoid
Do last Do second
Low High
Value
Low
High
Risk

51. Story Writing Prioritization
Epic Name Story Id As a I want So that Acceptance
Criteria
Assumptions MoSCoW Value Point Risk Point
A A.1
A A.2
A A.3
A A.4
B B.1
B B.2
B B.3
Story Prioritization – Template is evolving

52. Estimation

53. Sizing in Scrum – Story Points
• Sizing in Scrum is performed using STORY POINTS
• Sizing using story points is a relative concept, It is unit less in nature
• A user story estimated as 10 story points is twice as big or risky as a
story estimated as 5 story points
• What matters are the relative values assigned to a different stories
How long
will it take
to do
How difficult
will it be to
do
How unsure
are we of the
requirements or
implementation
SIZE = Effort x Complexity x Uncertainty
• Everyone estimates the whole size (design, code, test, etc.)

54. Velocity
• Velocity measures output (the size of what was delivered), not
outcome (the value of what was delivered)
• Velocity is the amount of work completed in each sprint
• Measured by adding the sizes of stories delivered in the sprint
• Doesn’t include work partially delivered
• Server two important purposes
• Used for planning
• Team’s commitment in a sprint

55. Value Sample Meaning
0 No Effort required
1 Extra Small
2 Small
3 Medium
5 Large
8 XL
13 XXL
20 Not doable in a Sprint
40 Spans multiple sprints
100 Throughout the Release
? … Need more information
Based on
Fibonacci sequence, a
recurring organizational
pattern
The story point scale has
no statistically reliable
relationship to man
hours
Typical parameter to
consider : Complexity,
Uncertainty, Effort
involved, Dependencies
etc
Story Point – Scale

56. Estimation Techniques – Story Point Estimation

57. Simultaneously
,
each
person
shows
estimate
Ea
ch person
chooses
their
es
timate
People with high & low
estimates
explain their
reasoning
Team discusses
User
Story
Until the
number
s are
clos
e
Story Points Estimation with Planning Poker

58. Backlog template
Story Writing Prioritization Estimation
Epic Name Story Id As a I want So that Acceptance
Criteria
Assumptions MoSCoW Value Point Risk Point Story point
A A.1
A A.2
A A.3
A A.4
B B.1
B B.2
B B.3

59. Finding the IRON Triangle

60. Release Planning Exercise
Scenario 1: A team has an average velocity of 24 story points.
The product backlog contains 75 stories.. 40 Must have, 20 Should have & 15 Could have
Size of the product backlog is 256 story points.
How many iteration will take take ideally?
Now, we are adding the buffer of 35% over the backlog, then how many iterations are we
going to take?
Scenario 2: Lets say, management wants to know how much time will be take to finish all the
Must & Should stories?
<velocity is 24 sp, buffering% remains same>
After some time, the velocity went down to 17 sp, now how many iterations are you going to
take?

61. THANK YOU
Anuj M Ojha
www.Benzne.com