Understanding agile
0 likes253 views
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.
Understanding agile
- 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 !