Easy Agile

Sprint Planning What is it? In textbook Scrum, the purpose of the Sprint Planning Meeting is for the entire team to agree to complete a set of ready top-ordered product backlog items. This agreement will define the sprint backlog and is based on the team’s velocity or capacity and the length of the sprint timebox. Who does it? Sprint planning is a collaborative effort involving: ScrumMaster – to facilitate the meeting Product Owner – to clarify the details of the product backlog items and their respective acceptance criteria Entire Agile Team –to define the work and effort necessary to meet their commitment to complete product backlog items Before You Begin Ensure all items to be discussed meet the teams definition of “ready”, to include (for example): relative story point value dependencies removed testable examples clearly defined acceptance criteria All items to be discussed reflect the greatest needs as identified by the Product Owner at th

Retrospective Attendees Required:  development team, scrum master, product owner When:  At the end of an iteration. Duration:  60 minutes. Agile Framework:  Scrum and Kanban. Scrum teams do sprint retrospective based on a fixed cadence. Kanban teams can benefit from occasional retrospectives, too. Purpose:  Agile is about getting rapid feedback to make the product and development culture better. Retrospectives help the team understand what worked well–and what didn't. Retrospectives aren't just a time for complaints without action. Use retrospectives to find out what's working so the team can continue to focus on those areas. Also, find out what's not working and use the time to find creative solutions and develop an action plan. Continuous improvement is what sustains and drives development within an agile team, and  retrospectives are a key part of that. 

Sprint review Attendees Required:  development team, scrum master, product owner Optional:  project stakeholders When:  At the end of a sprint or milestone. Duration:  30-60 minutes. Agile Framework:  Scrum and kanban. Like planning, review for kanban teams should be aligned with team milestones rather than on a fixed cadence. Purpose:  Iteration review is a time to showcase the work of the team. They can be in a casual format like "demo Fridays", or in a more formal meeting structure. This is the time for the team to celebrate their accomplishments, demonstrate work finished within the iteration, and get immediate feedback from project stakeholders. Remember, work should be  fully  demonstrable and meet the team's quality bar to be considered complete and ready to showcase in the review. 

Daily stand-up Attendees Required:  development team, scrum master, product owner Optional:  team stakeholders When:  Once per day, typically in the morning. Duration:  No more than 15 minutes. Don't book a conference room and conduct the stand up sitting down. Standing up helps keep the meeting short! Agile Framework:  Scrum and Kanban. Purpose:  Stand-up is designed to quickly inform everyone of what's going on across the team. It's not a detailed status meeting. The tone should be light and fun, but informative. Have each team member answer the following questions: What did I complete yesterday? What will I work on today? Am I blocked by anything? There's an implicit accountability in reporting what work you completed yesterday in front of your peers. No one wants to be the team member who is constantly doing the same thing and not making progress. 

Sprint planning Attendees Required:  development team, scrum master, product owner When:  At the beginning of a sprint. Duration:  Usually an hour per week of iteration–e.g. a two-week sprint kicks off with a two-hour planning meeting. Agile Framework:  Scrum. (Kanban teams also plan, of course, but they are not on a fixed iteration schedule with formal sprint planning) Purpose:  Sprint planning sets up the entire team for success throughout the sprint. Coming into the meeting, the  product owner  will have a prioritized product backlog. They discuss each item with the development team, and the group collectively estimates the effort involved. The development team will then make a sprint forecast outlining how much work the team can complete from the product backlog. That body of work then becomes the sprint backlog.

Challenges in Traditional Software Development Mothodologies The Traditional software development model follows a sequential life cycle called "the waterfall". The Waterfall model has different distinct phases like Requirements, Analysis, Design, Codi, g, Testing and maintenance. In this sequential flow, the duration of a project is very long ranging from few months to few years. The end user is not able to test the product till the end of the project and at the time of user acceptance testing the end user finds that the product is not delivering the functionality what he was expecting. There is a famous Swing Cartoon which shows comically what the customer is expecting and finally what the development team delivers. 1. High costs and wasted budgets Traditional methods can be quite costly and often 65% of the budgets spent on developing these methods is wasted on developing features that may not be used or required by the cu