Session Title: Guesstimating the timeline for backlog items
Abstract: Even with agile and lean mindset, focus never shift on getting a correct estimating process for each backlog item. This includes techniques like swarming, System Thinking, Value Stream Mapping, DOR and DOD creation, TDD/ATDD/BDD, XP concepts etc. which can be used efficiently to get the best results and faster delivery estimates.
Key Takeaways:
1. End to End estimation process to get an estimate of each backlog item.
2. Lean concepts like System Thinking, VSM, Swarming, Little law, etc., to fasten the process of delivery
3. Glimpse of various metrics that help monitor the progress of the project.
Agile Network India | Guesstimating the timeline for backlog items
1. Guesstimating the timeline for backlog
items
Understanding the best practices
that make guessing backlog Items
more accurate
2. Agile Mindset Quotes
“Perfection is not attainable, but if we chase perfection, we can catch excellence.”
“Teamwork occurs when diverse abilities and insights join together to work toward a common goal.”
“Agile is about doing as opposed to being paralyzed; in agile you get the minimal necessary and start
working.”
“Vision without action is a daydream, but action without vision is a nightmare.”
“Accountability means to say what you do, do what you say.”
“Cooperation is the thorough conviction that nobody can get there unless everybody gets there.”
“The strength of the team is each individual member. The strength of each member is the team.”
“Progress is impossible without change, and those who cannot change their minds cannot change
anything.”
“Be the change that you wish to see in the world.”
3. Problems to estimate properly
● Dependencies between teams. Multiple teams working on an initiative/PBI.
● Team members partially allocated.
● Teams keeps changing. Teams aren’t stable.
● Interruptions like production issues etc.
● Team estimates as if they were full-time dedicated.
● Priorities of initiative/PBI changes.
● New work altogether.
● Striving to hit a pre-assigned date by management.
● Risks not taken into account.
● Architectural vision or work to be done is unclear.
● Unavailability of important team members.
● Task divided between multiple teams.
● Tasks not created.
● Trust factor between teammates end up adding buffer.
4. Factors that help to get proper estimates
● Factors to consider while sprint planning
○ Creation of Task Pipeline (Pre-Planning Sessions)
○ DOR and DOD
● Factors to consider while sprint execution (Coding & System Testing)
○ Kanbanize the scrum (WIP and Pull System)
○ Swarming
○ TDD, ATDD and BDD
○ CI/CD Pipeline (DevOps)
● Factors to consider while Retrospecting
○ Value Stream Mapping
○ System Thinking
● Factors to consider while doing Testing
● Useful Metrics
○ Burn up and Burn down
○ CFD & Little’s Law
○ Iteration and Program Metrics
○ Team’s Self-Assessment & Program Self-Assessment
○ DevOps Health Chart
6. Creation of Task Pipeline (Pre-Planning Sessions)
1. Pre-planning - Start at least 3-5 days before the sprint starts.
2. First 2 days (1 hour session daily) - Discuss the stories functionally -
a. Understand what is needed by PO.
b. Ask Doubts/Queries and get them resolved
3. Next 3 days (1 hour session daily) - Discuss the stories technically. Here, find the following per story -
a. The technical components used
b. The interactions between technical components
c. The dependencies
d. The assumptions
e. The constraints
f. The risk and the mitigation plan
g. The testing related activities - acceptance criteria and amount of testing required
h. The rework and refactoring required, if any
i. The spikes, if any
j. The technical debt that will be created, if any
4. Create a pipeline of activities based on above details viz., create tasks for each story.
5. Use the Pipeline in planning which will be used for retrospective as well.
6. See my article for more details - https://www.linkedin.com/pulse/su-ha-ri-agile-planning-practical-sprint-
estimation-amit-medhekar/
7. DOR and DOD
● Benefit of DOR on estimation process -
○ Time and efforts are utilised rightly when actual planning is done.
○ Dependencies, risks and assumptions are identified early making team confident about estimates
shared.
○ Enables accurate estimation.
○ Reduce “requirements churn" in development.
○ Keep the team accountable to each other.
○ Reduction of conflict between the development team and the PO.
● Benefit of DOD on estimation process -
○ Helps to get feedback for improvement for estimates for future sprints.
○ Time and efforts are utilised rightly when actual execution happen.
○ Improves planning to release.
○ Minimizes the Delay Of Risk.
○ Keep the team accountable to each other.
○ Reduction of conflict between the development team and the PO.
10. Kanbanize Scrum
Benefits of ScrumBan system:
● Helps in limiting work in progress (reduces
waste).
● Along with CFD, helps identify bottlenecks in the
process (See CFD and Little’s law in metrics
section).
● Enables smoother flow.
● Enables swarming.
● Enables cross-functioning.
● Enables managing capacity.
● Help us Identify opportunities for process
improvement.
● Introduce slack into the system.
● Lead Time, Cycle Time and Process Efficiencies
are the metrics that help in estimation.
11. Swarming
Benefits of Swarming:
● Faster resolution of work or defect.
● Maximized chances for success with the skills and
abilities of the entire team focused on a single
requirement.
● Faster lead time.
● Optimized WIP.
● Smooth flow.
● Faster Failure.
● Broader team understanding.
● Improves cross-functioning.
● Real-time code review.
● Potential time savings.
12. TDD, ATDD and BDD
TDD ATDD BDD
It describes the cycle of writing a test
first, and application code afterwards
– followed by an optional refactoring
It Is a collaborative practice where
users, testers, and developers define
automated acceptance criteria.
It is a design activity where you build
pieces of functionality incrementally
guided by the expected behavior.
Developer’s perspective Customer, Developer & Tester Customer, Developer & Tester
Unit Testing Acceptance Criteria Requirements
Focus on implementation of feature Focus on capturing of requirement Focus on behaviour of feature
Benefits:
● Reduced time for feedback/Fast Feedback.
● Improved code quality/Reduced Rework
● Improved collaboration
● Clear acceptance criteria
● Prepared for automated testing
● Improved Developer / Tester / PO
communication
● Agreement on requirements
13. CI/CD Pipeline - DevOps
Benefits:
● Ensure faster time-to-market/delivery
times that improves ROI.
● Improve collaboration between teams
(Business / Dev / Ops).
● Stable/reliable operating environments
● Fail Faster - Early detection and faster
correction of defects.
● Improved code quality - Automated
environment migration resulting in less
human errors.
16. System Thinking
● System thinking is school thought that focuses on recognizing the interconnections between the parts of a
system and synthesizing them into a unified view of the whole.
● Causal Loops - Cause and effect and applies learning to create improved decisions and actions.
18. Testing
Discussion Points:
● Integration Testing & Regression Testing
to be done with separate teams.
● In SAFe, the system team is used for the
above activities -
○ Integration team - One sprint
behind the development team
○ Regression team - Separate cycle for
them as they are aligned to release
on demand.
○ If regression team is not working for
release on demand, it is one sprint
behind the integration team.
20. Burn up and Burn Down
How to use:
● Burn Down should be used at sprint
level. Benefits:
○ Simple
○ Shows Remaining work
○ Helps Inspect and Adapt
● Burn Up should be used at release level.
Benefits:
○ Simple again
○ Show completed work
○ Helps identify Scope Creep
○ Helps Inspect and Adapt
21. CFD & Little’s Law
CFD:
CFD should be used at sprint level. Benefits:
● Identify Bottlenecks
● Helps calculate Lead Time, WIP &
Throughput
Little’s Law:
● The seminal law of queuing theory—tells us
that the average wait time for service from a
system equals the ratio of the average
queue length divided by the average
processing rate.
● Hence, teams that limit WIP will get their
work done faster.
○ Lead time — how long it takes, on
average, for an item to get through the
system.
○ WIP — the average number of items in
the system at any point in time.
○ Throughput — the number of stories
completed per period of time viz.,
Throughput =WIP/Lead Time
