1. Agility is all about driving value! Vibhu Srinivasan vibhu@agilefaq.net “Its important to be agile not to do agile”
2. Agenda Visiting the Agile Manifesto. Product Owner Team. Metascrum User stories What are they . Your role on Agile team. Planning and estimation. Next Steps.
3. Agile ManifeSTO We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.
4. Core Values/ Principles Our highest priority is to satisfy the customerthrough early and continuous deliveryof valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Commitment Focus Openness Respect Courage
12. Agenda Visiting the Agile Manifesto. Product Owner Team. Metascrum User stories What are they . Your role on Agile team. Planning and estimation. Next Steps.
13. Product Owner Team AKA Product Definition Team None of us is as smart as all of us – Ken Blachard
14. Scaling ScSScaling rum – Issues Scaling Agile Issues Parallel teams Multiple goals Shared resources Product owners are tasked with carrying the product backlog and be always prepared for all sprint planning meetings.
19. Your PDT is now meeting many times a week 100 Percent Committed ABC– Chief Product Owner XYZ– Area Product Owner AGS– Area Product Owner ADF– Area Product Owner - Area Product Owner. This group clearly are the product managers and own the backlog Around 30 percent Developers ,Testers, architects, UX etc. This group is primarily to help the backlog be more accurate.
20. A few changes !! PDT will keep the various backlogs constantly groomed They own the roadmap , but the teams directly add a realistic view to the roadmap by doing release planning Scrum masters need not have to schedule repeated grooming sessions. The PDT should be doing this. As always this group will inspect and adapt.
21. Agenda Visiting the Agile Manifesto. Product Owner Team. Metascrum User stories What are they . Your role on Agile team. Planning and estimation. Next Steps.
23. Metascrum Defined Attended by key stakeholders, product definition team, scrum masters and architect and sometimes team members This meeting has a strategic intent unlike the tactical intent of daily scrum. In a Metascrum you discuss where all these features are in flight as compared to the overall roadmap for that group. This is a place to resolve any impediments the teams have not been able to resolve on their own. This group meets every two weeks now on a thursday
24. Agenda Visiting the Agile Manifesto. Product Owner Team. Metascrum User stories. Your role in your agile team. Next Steps.
26. User story A piece of functionality that is needed to add value to the product. A good story has well defined acceptance criteria. The three C’s of a User Story C = Card C = Conversation C = Confirmation
27. More on user stories User stories bring in the notion of just in time requirements You don’t need use cases. Stories are enough if you have a good product owner. Stories are only complete with acceptance criteria. You can say “NO” to working on stories if the team does not get what the story means. You should give input to the order the stories are built. You may know of dependencies that product owners don’t.
28. Every story you take should pass the invest model test. I – Independent N – Negotiable V – Valuable E - Estimable S - Small T - Testable
29. User story - what it does not have! Technical specifications All the details up front like in a use case or functional specification. Database fields Product owners should tell the “what” not the “how”
30. What about technical stories ? The shiny bunny problem Every sprint the team could buy certain story points to work on technical stories, like enhanced logging, implementing a MVC etc Architects may have some points too for some of their larger initiatives. But always show value in your stories – Write them as abusive stories, word them in a way a product owner will see value.
31. Product Backlog A collection of user stories, well prioritized by the product owner is a backlog Please ask your product owner or your PDT about where your backlog is Backlog never ends, the product owners can choose to ship at any point they see value.
32. “Customers have the right to demand working software but they should respect your estimates”
33. Roadmap and release plan Teams should know what their roadmap is. Ask your product owner where the roadmap is? You should know the product vision, the roadmap, when your next release plan is or where it is?
34. Agenda Visiting the Agile Manifesto. Product Owner Team. Metascrum User stories. Your role in your agile team. Next Steps.
35. Your role is an agile team What you need is testing not tester. Developing not developer. The shift from I – We – Us is very tough Remember the art of active listening.
36. Your role is an agile team What you need is testing not tester. Developing not developer. The shift from I – We – Us is very tough Remember the art of active listening.
37. Agile team characteristics Self organizing Inspect adapt nature Deliver Frequently Communicate and listen well They believe in testing well. They always can show value in work they do They keep an eye on the baton not the runners.
38. Agenda Visiting the Agile Manifesto. Product Owner Team. Metascrum User stories. Your role in your agile team. Next Steps.