Understanding Agile
By: Varun Hooda
Product Backlog
• Product backlog is a list of thing or say user stories that
people want to be done to the product, in pr...
Estimate Your Product Backlog
• You need to provide some high-level initial
estimates, in order to get an idea of the size...
Sprint Planning
• Scrum suggests, sprint duration 30 days
• 2 week Sprints for fast moving products
• First of all, calcul...
A Collaborative workspace
• Whiteboard your walls
• Create a place for Collaboration
• Mark up a whiteboard with 5 columns...
Sprint
• The Scrum team makes its own decisions during the Sprint. The
team is empowered. Every time a manager steps in an...
Sprint
• Testing starts at the start of the Sprint. In fact, it
starts earlier than that. It starts in Sprint
Planning, as...
Stand Up And Be Counted
• Hold a daily stand-up meeting. The whole team must be
present.
• The whole team must be involved...
Finish When You Said You Would
• There are a few key principles of agile software
development
• ‘done’ means DONE!
• Time ...
Review, Reflect, Repeat
• At the end of the Sprint, hold a Sprint Review meeting.
Invite the whole team.
• Review what was...
• This post is from Kelly Waters's Blog. See more
at: http://www.allaboutagile.com/how-to-
implement-scrum-in-10-easy-step...
Thank You !
Upcoming SlideShare
Loading in …5
×

Understanding agile

193 views

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
193
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Understanding agile

  1. 1. Understanding Agile By: Varun Hooda
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 12. Thank You !

×