Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

Scrum presentation jyoti

Nächste SlideShare
Scrum Framework
Scrum Framework
Wird geladen in …3
×

Hier ansehen

1 von 22
1 von 22

Weitere Verwandte Inhalte

Ähnliche Bücher

Kostenlos mit einer 30-tägigen Testversion von Scribd

Alle anzeigen

Ähnliche Hörbücher

Kostenlos mit einer 30-tägigen Testversion von Scribd

Alle anzeigen

Scrum presentation jyoti

  1. 1. Scrum Process
  2. 2. Agile is a continuous iteration of development and testing in the software development process whereas Scrum is an Agile process to focus on delivering the business value in the shortest time. Agile methodology delivers the software on a regular basis for feedback while Scrum delivers the software after each sprint. What is Scrum
  3. 3. The Three Pillars of Emprircism (Scrum) Empiricism means working in a fact-based, experience-based, and evidence-based manner. Scrum implements an empirical process where progress is based on observations of reality, not fictitious plans. Scrum also places great emphasis on mind-set and cultural shift to achieve business and organizational Agility. •Transparency: This means presenting the facts as is. All people involved—the customer, the CEO, individual contributors—are transparent in their day-to-day dealings with others. They all trust each other, and they have the courage to keep each other abreast of good news as well as bad news. Everyone strives and collectively collaborates for the common organizational objective, and no one has any hidden agenda. • Inspection: Inspection in this context is not an inspection by an inspector or an auditor but an inspection by every- one on the Scrum Team. The inspection can be done for the product, processes, people aspects, practices, and continuous improvements. For example, the team openly and transparently shows the product at the end of each Sprint to the customer in order to gather valuable feedback. If the customer changes the requirements during inspection, the team does not complain but rather adapts by using this as an opportunity to collaborate with the customer to clarify the requirements and test out the new hypothesis. • Adaptation: Adaptation in this context is about continuous improvement, the ability to adapt based on the results of the inspection. Everyone in the organization must ask this question regularly: Are we better off than yesterday? For profit-based organizations, the value is represented in terms of profit. The adaptation should eventually relay back to one of the reasons for adapting Agile—for example, faster time to market, increased return on investment through value- based delivery, reduced total cost of ownership through enhanced software quality, and improved customer and employee satisfaction. Scrum works not because it has three roles, five events, and three artifacts but because it adheres to the underlying Agile principles of iterative, value-based incremental delivery by frequently gathering customer feedback and embracing change. This results in faster time to market, better delivery predictability, increased customer responsiveness, ability to change direction by managing changing priorities, enhanced software quality, and improved risk management. Scrum ensures discipline in the processes You can evaluate whether you’re getting more throughput, delivering more value and where you need to make improvements
  4. 4. The key difference between Agile and Scrum is that while Agile is a project management philosophy which utilizes a core set of values or principles, Scrum is a specific Agile methodology that is used to facilitate a project Difference between Agile & Scrum While Agile and Scrum follow the same system, there are some differences when comparing Scrum vs Agile. Agile describes a set of principles in the Agile Manifesto for building software through iterative development. On the other hand, Scrum is a specific set of rules to follow when practicing Agile software development. Agile is the philosophy and Scrum is the methodology to implement the Agile philosophy. Because Scrum is one way to implement Agile, they both share many similarities. They both focus on delivering software early and often, are iterative processes, and accommodate change. They also encourage transparency and continuous improvement. Agile and Scrum share similar methods like collaborative iterations, and for a good reason: Scrum is an Agile approach. But while both involve incremental builds for projects, they also have their differences. Scrum is a more rigid method with less flexibility for change, and it’s ideal for those who need to produce results as quickly as possible. Agile is more suited for smaller teams and for those who prefer a more straightforward design and execution, while Scrum is used more for creative and experimental approaches. It's best to look at it this way: Scrum is always Agile, but Agile is not always Scrum. This means Scrum will encompass the same methodologies of Agile, but Agile may not share some of the same qualities as Scrum.
  5. 5. The Scrum Values
  6. 6. The Scrum’s Simple Rule
  7. 7. The Scrum Team
  8. 8. The Scrum Master The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values. •Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible; •Finding techniques for effective Product Backlog management; •Helping the Scrum Team understand the need for clear and concise Product Backlog items; •Understanding product planning in an empirical environment; •Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value; •Understanding and practicing agility; and, •Facilitating Scrum events as requested or needed. Product Owner Development Team Organization •Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible; •Finding techniques for effective Product Backlog management; •Helping the Scrum Team understand the need for clear and concise Product Backlog items; •Understanding product planning in an empirical environment; •Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value; •Understanding and practicing agility; and, •Facilitating Scrum events as requested or needed. •Coaching the Development Team in self- organization and cross-functionality; •Helping the Development Team to create high-value products; •Removing impediments to the Development Team’s progress; •Facilitating Scrum events as requested or needed; and, •Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood. •Leading and coaching the organization in its Scrum adoption; •Planning Scrum implementations within the organization; •Helping employees and stakeholders understand and enact Scrum and empirical product development; •Causing change that increases the productivity of the Scrum Team; and, •Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.
  9. 9. Stories keep the focus on the user. A To Do list keeps the team focused on tasks that need checked off, but a collection of stories keeps the team focused on solving problems for real users. Stories enable collaboration. With the end goal defined, the team can work together to decide how best to serve the user and meet that goal. Stories drive creative solutions. Stories encourage the team to think critically and creatively about how to best solve for an end goal. Stories create momentum. With each passing story the development team enjoys a small challenges and a small win, driving momentum. Why create user stories? A user story describes the type of user, what they want and why. A user story helps to create a simplified description of a requirement. The purpose of a user story is to articulate how a piece of work will deliver a particular value back to the customer. User stories are a few sentences in simple language that outline the desired outcome. They don't go into detail. Requirements are added later, once agreed upon by the team. User Story
  10. 10. Product Backlog Collection of all the User Stories is called Product Backlog A team's roadmap and requirements provide the foundation for the product backlog The Product Owner is the sole person responsible for managing the Product Backlog Product Backlog management includes: Clearly expressing Product Backlog items; Ordering the items in the Product Backlog to best achieve goals and missions Optimizing the value of the work the Development Team performs Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next Ensuring the Development Team understands items in the Product Backlog to the level needed
  11. 11. A sprint backlog is the set of items that a cross-functional product team selects from its product backlog to work on during the upcoming sprint. The development team is responsible for sprint backlog management and owns the sprint backlog The development team should communicate with the product owner if they discover they cannot complete a task The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a "Done" Increment. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a "Done" Increment. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team. Sprint Backlog
  12. 12. Product Backlog V/S Sprint Backlog
  13. 13. Release Planning Release planning is longer- term planning that enables us to answer questions like “When will we be done?” or “Which features can I get by the end of the year?” or “How much will this cost?” Release planning is about making the scope, date, and budget trade- offs for incremental deliveries. It is all about ‘high-level planning’ of multiple sprints (three to twelve iterations). Most of the times, it is sensible and important to carry out Initial Release Planning after product planning and before beginning the first Sprint related to the Release. At this point, you can make an initial release plan showing a balance between how much can be built in the release against when the release will be available. You can generate and estimate a sufficient number of product backlog items to get an idea of when you can deliver a fixed set of features.
  14. 14. Sprint In the Scrum Framework all activities needed for the implementation of entries from the Scrum Product Backlog are performed within Sprints (also called 'Iterations'). Sprints are always short: normally about 2-4 weeks. Each Sprint start with two planning sessions to define the content of the Sprint: the WHAT- Meeting and the HOW-Meeting. The combination of these two meeting are also defined as Sprint Planning Meeting. In the WHAT- Meeting the Scrum Team commits to the User Stories from the Scrum Product Backlog and it uses a HOW-Meeting to break the committed User Stories into smaller and concrete tasks. Then implementation begins. At the end of the Sprint a Sprint Review Meeting is conducted to allow the Scrum Product Owner to check if all of the committed items are complete and implemented correctly. Additionally a Sprint Retrospective Meeting is conducted to check and improve the project execution processes: What was good during the Sprint, what should continue as it is and what should be improved. During the Sprint a short daily Standup-Meeting (Daily Scrum Meeting) is held to update the status of the items and to help self- organization of the team.
  15. 15. 4 3 2 1 • Sprint Planning Meeting • Daily Scrum / Daily Work • Sprint Review • Sprint Retrospective Scrum Events - Sprint
  16. 16. Sprint Planning What Happens in Sprint Planning? During Sprint Planning, the entire Scrum Team collaborates and discusses the desired high-priority work for the Sprint and defines the Sprint Goal. The ScrumMaster’s role is primarily to facilitate the meeting. The Product Owner describes the objective of the Sprint and also answers questions from the Development Team about execution and acceptance criteria / criteria of satisfaction. The development team has the final say in how much of the high-priority work it can accomplish during the Sprint. Who attends Sprint Planning? Sprint planning involves the entire Scrum Team: the development team, product owner, and ScrumMaster. How long should Sprint Planning Last? Sprint planning is limited to a maximum of eight hours. The general rule of thumb is to allow two hours of sprint planning for every one week of sprint length. That means teams should timebox sprint planning to four hours for a two-week sprint and eight hours for a one-month sprint
  17. 17. Daily Scrum What Happens in a Daily Scrum? The Development Team meets for 15 minutes (or less) every day of the Sprint to inspect progress toward the Sprint Goal. They describe for each other how their own work is going, ask for help when needed, and consider whether they are still on track to meet the Sprint Goal. This is not a status meeting but is instead an opportunity for the Development Team to inspect and adapt the product and process on a daily basis. Who Attends the Daily Scrum? The mandatory participants at the Daily Scrum are the development team. The ScrumMaster typically attends but is optional. The product owner is invited but doesn’t have to attend.
  18. 18. Sprint Review What Happens in a Sprint Review? Sprint reviews focus on the product being developed, specifically on the potentially shippable product increment created during the sprint. During a sprint review, the Scrum Team invites stakeholders to discuss what was completed during the Sprint. They adapt the Product Backlog as needed based on this feedback. The Product Owner has the option to release any of the completed functionality. Though a demo might be part of this meeting, the primary purpose of the Sprint Review is the inspect and adapt capability provided by the discussion. Who Attends a Sprint Review? The entire Scrum Team attends the sprint review. Any stakeholders, senior managers, and other affected departments (e.g., marketing, customer support) are invited to attend and give feedback. Scrum teams should invite as many people as the room can hold--diverse feedback is essential for creating excellent products. How Long Should Sprint Reviews Last? Sprint reviews are limited to a maximum of four hours. The general rule of thumb is to allow one hours for sprint review per every one week of sprint length. That means teams should timebox sprint review to two hours for a two-week sprint and four hours for a one-month sprint.
  19. 19. Sprint Retrospective What Happens in a Sprint Retrospective? Sprint retrospectives focus on the process. During a sprint retrospective the Scrum Team discusses what went right and areas for improvement in the Sprint. They make tangible plans for how to improve their own process, tools and relationships. What Is the Difference between Sprint Reviews & Sprint Retrospectives? Sprint reviews focus on the product. Sprint Retrospectives focus on the process. Who Should Attend a Sprint Retrospective? Sprint retrospectives are for the Scrum Team, which would include the development team, ScrumMaster, and product owner. In practice, product owners are recommended but not mandatory attendees. How Long Should Sprint Retrospectives Last? Sprint retrospectives are limited to a maximum of three hours. The general guidance is to allow 45 minutes for each week of sprint length. So a two-week sprint would cap the sprint retrospective at an hour and a half; a four-week sprint at three hours.
  20. 20. Thank You

×