Many a times, we see that a single team is responsible for development, QA and support for the product. It’s a challenging environment when multiple fix packs for older versions and a fresh new release goes in parallel and the team has recently adapted to agile practices. In this session, I would detail out a case study and highlight the challenges we faced in our early sprint cycles, how we learnt lessons and applied them to the next sprints and effectively improved upon our deliverables. The following concepts will be covered in this session 1.Being Agile – Effective Planning for the sprints (both Dev and QA) 2.Preparing for the deliverables – defining mile stones (For the sprint) 3.Better delivery – Effective scrums Audience: Teams following or new to agile methods Audience will be able to learn the techniques used to plan and deliver sprint items in better way. Challenges presented during the case study would serve as learning to the audience so that those mistakes can be avoided while applying these methods practically.

1. Smarter Sprint Cycles, Better
Deliverables
Suma C Shastry
IBM India Pvt Ltd

2. Agenda

Introduction

Challenges

Lessons Learnt

Best Practices Followed

Key Benefits

Q&A
2

3. Introduction
• Complete ownership of
products
– Development
– Testing
– Level 3 Support
• Multiple fix pack releases
• New release planned
3

4. Challenges

Very New to Agile

More releases, less resources!

Ad Hoc communication mechanism
4

5. Challenges

HLD not available early

Wrong Defects for the Sprint

Late Critical defects

ID Team not aware of requirement

Combined Burn down charts for new
development and support items
5

6. Result

Last minute hurry

Defect Back log

Escalations

Team’s low moral

Not so happy ending

7. Lessons Learnt

Education on Agile

Communication protocol

Escalation mechanism

HLD to be ready early

Identification of ID requirements

Focus on the sprint items

Early Test blockers

8. Best practices

Plan the sprint early
− Always before the current sprint ends
− Probable sprint items are decided and
communicated well in advance
− QA team meets prior to sprint meeting

Can we cover these items?

Do we need extra infrastructure?

Could some of the items be dropped?

Could there be some new additions?

Do we have enough resources?

9. Best practices

Dev, QA and ID Owners identified

Identify sprint items

Define check points
− HLD Available ?
− Test plan ready?
− ID defects opened?
− Any other dependencies?
− Any specific coverage required?

10. Best practices

Define Internal milestones
− Development start
− Demo to QA team
− QA Complete
− Defect fixes, verification
− Go from QA
− Sprint Demo to L2 and teams

11. Best practices

Communication protocol &
Escalation mechanism defined
− Pre defined time slots for discussion
− Scrums to discuss on daily progress

12. Best practices

Defects, issues, observations tracked
daily
− Test blockers notified to dev team
− Known issues tracked separately
− Scrum master to track and prepare a
status chart for every sprint

13. Best practices

Separate Burn down charts

Sprint reflection meeting
and Feedback after every
sprint

14. Key Benefits

Timely Deliverables
− Reduction in invalid defects
− Focused testing
− Critical and Test block defects
found early in cycles
− ID work could start parallely
− Continuous learning

15. Key Benefits

Confident Team
− Better managed work load
− Less stressed team members
− Happy management 