The document discusses key aspects of agile product development using Scrum methodology. It explains that the product backlog is a prioritized list of user stories and requirements created by the product owner. It also describes estimating backlog items, sprint planning which involves estimating tasks and setting a fixed sprint duration, daily stand-ups to track progress, and sprint reviews and retrospectives to reflect on each sprint. The overall process is iterative with sprints, backlog refinement, and continuous improvement.

1. Understanding Agile
By: Varun Hooda

2. Product Backlog
• Product backlog is a list of thing or say user stories that
people want to be done to the product, in priority order.
• User stories should be testable
• Anyone can add anything to the Product Backlog
• But… very importantly – only the Product Owner can
prioritize the Product Backlog.
• The Product Backlog can contain anything. Anything
relating to the product that is. Bugs. Enhancements. Whole
projects. Issues. Risks. Anything
• It can have both functional and non functional requirement
• Product Backlog should ideally be expressed in business
terms that are of some value to the user (or customer, or
business). Not as technical tasks.

3. Estimate Your Product Backlog
• You need to provide some high-level initial
estimates, in order to get an idea of the size of
your product backlog items
• it helps to inform the decision about priorities
• Use Fibonacci number for guestimates

4. Sprint Planning
• Scrum suggests, sprint duration 30 days
• 2 week Sprints for fast moving products
• First of all, calculate the team’s Sprint Budget. This is the available
number of hours the team has to work on the
• Go through each Product Backlog item selected for the Sprint.
Break the requirements into tasks.
• Each of these tasks, especially development, may be broken down
further. Maybe to a component level detailing each of the individual
elements of the software architecture that will be required to
deliver the feature of the product.
• Include all tasks necessary to make the Product Backlog item 100%
complete – i.e. potentially shippable – within the Sprint
• Keep tasks small. Estimate all tasks in hours. Estimate each task as a
team.

5. A Collaborative workspace
• Whiteboard your walls
• Create a place for Collaboration
• Mark up a whiteboard with 5 columns. You
can add more if you want to. But at least do
these. Label the columns: Product
Backlog, Tasks To Do, Work In Progress, Ready
To Be Verified and Done

6. Sprint
• The Scrum team makes its own decisions during the Sprint. The
team is empowered. Every time a manager steps in and makes a
decision for the team, they remove some responsibility from the
team. If a manager keeps doing this, the team gradually – piece by
piece – loses ownership, along with their commitment.
• The timeframe – in this case the Sprint Duration – is fixed. You can
add scope if you absolutely must, or add tasks if you discover they
are needed.
• If you finish early, include more scope, i.e. the next most important
thing on the Product Backlog. If you look like you’re going to finish
late, you must reduce scope in order to hit the deadline
• make sure you complete one feature at a time before moving on to
the next. You need to avoid reaching the end of the Sprint Duration
with 90% of everything. 90% of everything allows you to deliver
nothing. It’s better to have 100% of something.

7. Sprint
• Testing starts at the start of the Sprint. In fact, it
starts earlier than that. It starts in Sprint
Planning, as involving testers at the start helps to
clarify requirements. Writing the tests before a
feature is built, means developers have more of a
tendency to build the code to pass. Test driven
development starts here.
• Constant changes to priorities prevent a
development team from being fully productive
and in the worst case can prevent a development
team from delivering at all.

8. Stand Up And Be Counted
• Hold a daily stand-up meeting. The whole team must be
present.
• The whole team must be involved. Including, very
importantly, the Product Owner
• Each team member reports back to the team in turn. Only
the person reporting back should speak at one time.
• Their report should be concise and focused. Their report
should address 3 key questions:
1. What have they achieved since the last meeting?
(yesterday)
2. What will they achieve before the next meeting?
(tomorrow)
3. Is anything holding up their progress? (‘impediments’)

9. Finish When You Said You Would
• There are a few key principles of agile software
development
• ‘done’ means DONE!
• Time waits for no man!
If you hang on to the ‘done’ principle, you should be in a
position to ship when your time is up.
• All changes must be reversible
• Finish when you said you would
*Complete* each feature before moving on to the next. Stick
to the principle ‘done means DONE!’. Manage your code
carefully so you can build a shippable product at any time.

10. Review, Reflect, Repeat
• At the end of the Sprint, hold a Sprint Review meeting.
Invite the whole team.
• Review what was delivered in the Sprint. Demo the
software. Whether it’s complete, working software prior to
a release, or work-in-progress in a long-running multi-
Sprint project, demo what has been completed in the
Sprint. Let team members demo the areas they have
worked on.
• Hold a Sprint Retrospective meeting. Invite the whole team.
Together the team should:
• Discuss What went well.
• Discuss What didn’t go so well.
• Discuss What will be done differently going forward

11. • This post is from Kelly Waters's Blog. See more
at: http://www.allaboutagile.com/how-to-
implement-scrum-in-10-easy-steps-step-1-get-
your-backlog-in-order/#sthash.it6eoSeu.dpuf

12. Thank You !