Advanced agile slides by Anushree verma
- 1. Welcome to Agile Webinar Series OrganizedBy: ComputerSocietyofIndia MumbaiChapter www.csimumbai.org www.techxpla.com Foranyquestionduringthe webinaryoucantweetat #CSIMum
- 2. Webinar Series on Agile and Digital Marketing 1.IntroducingAgileDate:12/03/2016Time:11AM 2.AdvancedAgileDate19/03/2016Time11AM 3.ScrumFrameworkDate26/03/2016Time11AM 4.HowtostartmarketingwithzerobudgetforB2BITBusiness16/03/2016Time:11AM 5.InboundmarketingtipsandtricksforB2BITTechnologyBusiness23/03/2016Time:11AM 6.HowtosetupaffiliatemarketingforB2BIT/SaaSBusiness06/04/2016Time:11AM 7.HowtochoosedigitalagencyforITindustry22/03/2016Time:11AM 8.HowtotargetaccountbasedmarketingforITindustry29/03/2016Time:11AM 9.SocialMediaMarketingforITindustryB2Bmarketing05/04/2016Time:11AM
- 3. Upcoming Sessions Classroom Sessions in Mumbai & Online Sessions on Agile & Digital Marketing. Upcoming 2 days Workshop on Digital Marketing ; 1 day workshop on LinkedIN marketing. Online 16 hours Online training in April/May on Digital Marketing
- 4. Today’s Speaker Anushree Verma Technical Delivery Manager/Agile Coach, Capgemini Certified SCRUM Master(CSM) Certified Trainer from PMI(PMI) Certified Agile Professional Trained(PMI) Distributed Agilist PMP Trained ITIL Certified
- 6. Agenda • Relative vs. Absolute Estimating • Story Points • Planning Poker – Estimation Technique • Affinity Estimation Agile Estimation & Techniques Agile Prioritization • Story mapping & Prioritization • KANO Analysis • MoSCoW Analysis
- 7. Agile Estimation & Techniques Relative Estimating 1 2 3 4 5
- 8. Agile Estimating While we aren’t very good at estimating things absolutely , it turns out that we are pretty good in estimating things relatively
- 9. Agile Estimating Sizing things relatively means not worrying about exactly how big a story is ; but worrying more about how this story’s size compares to others
- 10. Agile Estimating Relative Estimating focuses on size and complexity - this happens at the story level. This style of estimation (relative over absolute) forms the corner stone of Agile Planning
- 11. Agile Estimating •Relative Estimating focuses on size and complexity •This happens at the story level •Estimation is done in Story Points Relative Estimating Absolute Estimating •Absolute Estimating focuses on ideal time • This happens at the task level • Estimated in hours
- 12. Agile Estimating Cone of Uncertainty
- 13. Agile EstimatingAgile Estimating • A story point is a numerical value assigned to the user story. Story points are primarily a measure of the degree of effort necessary to deliver the story functionality before the end of one sprint. Higher confidence is represented by a lower estimate. What is a story point • The point gives a picture of how big or small the story is in terms of execution Why • It’s a range from 1, 2, 3, 5, 8, 13, 20, 40, 100What is the numerical range
- 14. Agile EstimatingAgile EstimatingAgile Estimating Story Points 1 2 3 5 8 13 20 40 100 Simple one- liner change. No dependencies. Simple change. May have some localised dependencies. Requires test cases. More complex. May require some analysis to implement technical solution. Relatively complex but can be completed without a technical design. Technical design required. Many unknowns and dependencies. Difficult to estimate at this stage Many unknowns and dependencies. Difficult to estimate at this stage Too many unknowns or dependencies to provide any sort of estimate. Should be broken down into more manageable stories Fibonacci Scale for Stories Small Medium Med-large Large X-Large
- 15. Story points help drive cross-functional behavior Story point estimates don’t decay like time estimates Story points are a pure measure of size (estimate by analogy - “this is like that”) Estimating in story points is typically faster My ideal time is not your ideal time Agile Estimating Why use Story Points?
- 16. Agile EstimatingAgile EstimatingAgile Estimating Planning Poker
- 17. Agile EstimatingAgile EstimatingAgile Estimating Planning Poker 1. Scrum Master reads the story to Development Team. Development Team asks questions to the Product Owner to fully understand what is expected to be delivered. 2. Each member of the Development Team selects a card that reflects their estimate and, on the given signal, everyone turns over their card. 3. If there is not a unanimous estimate, the High and Low estimates explain why they selected their chosen estimate. The purpose is not to cajole someone into a particular vote, but to better understand the rationale. In most cases, the estimate was made based on incomplete information (‘I didn’t know the database already existed’) or on personal experience (‘In a similar project, it took a lot of effort to unit test’). 4. After discussing, the members select their estimates and shares with the Development Team and the process continues until the estimates converge at a single value. 5. Process continues through all the User Stories.
- 18. Prioritization in Agile A product backlog will contain all the features and functionality required to be delivered, but unlike waterfall, detailed planning need not be done upfront for the whole project Only features and functionalities for which details are available and provide the most value to the business are prioritized and worked in the sprint During planning sessions the Product Owner prioritize the backlog items based on the needs of the business across six attributes: Value Cost Risk Dependency Releasability Learning
- 19. Prioritization in Agile KANO Analysis •Must Haves - baseline features, dissatisfaction when these are absent. •Satisfiers - value added, the more of these the happier the customer is. •Delighters - exciting features, but not expected. •Indifferent - users don’t find value in these.
- 20. Prioritization in Agile MoSCoW Analysis
- 21. Prioritization in Agile MoSCoW Analysis Must Have •Cannot deliver on target date without this •No point in delivering on target date without this; if it were not delivered, there would be no point deploying the solution on the intended date •Not legal without it •Unsafe without it •Cannot deliver the Business Case without it
- 22. Prioritization in Agile MoSCoW Analysis Should Have •Important but not vital •May be painful to leave out, but the solution is still viable •May need some kind of workaround, e.g. management of expectations, some inefficiency, an existing solution, paperwork, etc. Could Have •Wanted or desirable but less important •Less impact if left out (compared with a Should Have) Wont Have These are requirements which the project team has agreed it will not deliver. This helps to manage expectations that some requirements will simply not make it into the delivered solution, at least not this time around.
- 23. MoSCoW Analysis Agile Release Planning Release-1 Release - 2 Release-3 Sprint-74 Sprint-33 Sprint-1 Sprint-2 Sprint-92 Sprint-8 • Walkthrough on the backlogs in the project • Review the release strategy, considering business needs. • Plan priorities and sprints accordingly Release Planning • Product Owner • Scrum Master • Key stakeholders Attendance • A set of deliverable timeline is establishedOutcome Sprint-63 Sprint-4 Sprint-5 Feature -2Feature -1
- 24. Agile Release Planning Every sprint should provide demonstrable progress to the business. In order to accomplish that, a sprint must include vertical slices of functionality. In this case the user story maps to one vertical slice containing three technical layers. Can all three of these be fully built at the end of one sprint? Maybe. The typical approach is to build the vertical slice incrementally over a series of sprints. 24 Database Webservices User Interface UI section with a sortable 6 column table 3 reusable services to populate the table 18 DB tables Vertical Slice User Story #45 Description: As a bookshop owner, I want to create the payment methods so that I can receive payments from shoppers AC: Payment Manual, Paypal Payment, Credit card payment Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Happy Path Alt flows, exceptions Revised view Logging, Auditing, etc. Tweaks Slice the cake
- 25. Thanks! Any Questions? You can find me at : Anushree.Verma@Capgemini.com +91 9890109427