Scrum Method
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
403
On Slideshare
379
From Embeds
24
Number of Embeds
2

Actions

Shares
Downloads
20
Comments
0
Likes
1

Embeds 24

http://djravindave.com 15
http://ravindave.wordpress.com 9

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. scrum A flexible, holistic product development strategy where a development team works as a unit to reach a common goal". http://en.wikipedia.org/wiki/Scrum_(software_development)
  • 2. Scrum | Overview Scrum is an iterative and incremental agile software development framework for managing software projects and product or application development. ● It challenges assumptions of the "traditional, sequential approach" to product development. ● Scrum enables teams to self-organize by encouraging physical co-location or close online collaboration of all team members and daily face to face communication among all team members and disciplines in the project. A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. ● As such, Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to deliver quickly and respond to emerging requirements.
  • 3. Scrum | Roles There are three core roles[8] and a range of ancillary roles; ● Core roles are often referred to as pigs and ancillary roles as chickens (after the story The Chicken and the Pig). ● The core roles are those committed to the project in the Scrum process—they are the ones producing the product (objective of the project). ● They represent the scrum team. ● Although other roles may be encountered in real projects, Scrum does not define any roles other than those described below.[9]
  • 4. Scrum | Roles | Project Owner The Project Owner (TPO) represents the stakeholders and is the voice of the customer. ● He or she is accountable for ensuring that the team delivers value to the business. ● TPO (or has the team write) customer-centric items (typically user stories), ranks and prioritizes them, and adds them to the product backlog. Note: ● Scrum teams should have one Product Owner, and while they may also be a member of the development team, this role should not be combined with that of the Scrum Master. ● In an enterprise environment, though, the Product Owner is often combined with the role of Project Manager as they have the best visibility regarding the scope of work (products).
  • 5. Scrum | Roles | Team Development Team ● The Development Team is responsible for delivering potentially shippable increments (PSIs) of product at the end of each Sprint (the Sprint Goal). ● A Team is made up of 3–9 individuals with cross-functional skills who do the actual work (analyse, design, develop, test, technical communication, document, etc.). ● The Development Team in Scrum is self-organizing, even though there may be some level of interface with project management offices (PMOs). Scrum Master ● Scrum is facilitated by a Scrum Master, who is accountable for removing impediments to the ability of the team to deliver the product goals and deliverables. ● The Scrum Master is not a traditional team lead or project manager, but acts as a buffer between the team and any distracting influences. ● The Scrum Master ensures that the Scrum process is used as intended. ● The Scrum Master is the enforcer of the rules of Scrum, often chairs key meetings, and challenges the team to improve.
  • 6. Scrum | Roles | Team Scrum Master ● The Scrum Master differs from a project manager in that the latter may have people management responsibilities unrelated to the role of Scrum Master. ● The Scrum Master role excludes any such additional people responsibilities. ● In fact, there is no role of project manager in Scrum at all, because none is needed. ● The traditional responsibilities of a project manager have been divided up and reassigned among the three Scrum roles, and mostly to the Development Team and the Product Owner, rather than to the Scrum Master. ● Practicing Scrum with the addition of a project manager indicates a fundamental misunderstanding of Scrum, and typically results in conflicting responsibilities, unclear authority, and sub-optimal results.[10]
  • 7. Scrum | Process | Sprint A sprint (or iteration) is the basic unit of development in Scrum. ● The sprint is a "timeboxed" effort; that is, it is restricted to a specific duration.[11] The duration is fixed in advance for each sprint and is normally between one week and one month, although two weeks is typical.[7] ● Each sprint is started by a planning meeting, where the tasks for the sprint are identified and an estimated commitment for the sprint goal is made, and ended by a sprint review-and- retrospective meeting,[4] where the progress is reviewed and lessons for the next sprint are identified. ● Scrum emphasizes working product at the end of the Sprint that is really "done"; in the case of software, this means a system that is integrated, fully tested, end-user documented, and potentially shippable.[10]
  • 8. Scrum | How it Works
  • 9. Artifacts | Product Backlog ● The product backlog is what will be delivered, ordered into the sequence in which it should be delivered. ● It is open and editable by anyone, but the Product Owner is ultimately responsible for ordering the items on the backlog for the Development Team to choose. ● Product Backlog items are articulated in any way that is clear and sustainable, whatever needs to be done in order to successfully deliver a viable product. ● The product backlog items (PBIs) are ordered by the Product Owner based on considerations like risk, business value, dependencies, date needed, etc. ● The product backlog contains the Product Owner's assessment of business value and the Development Team's assessment of development effort, which are often, but not always, stated in story points, using rounded Fibonacci sequence. ● These estimates help the Product Owner to gauge the timeline and may influence ordering of backlog items ● Items can be expressed as user stories, use cases, or any other requirements approach that the group finds useful. ○ But whatever the approach, most items should focus on delivering value to customers.
  • 10. Scrum | How it Works
  • 11. Artifacts | Product Backlog ● The sprint backlog is the list of work the Development Team must address during the next sprint. ● The list is derived by selecting product backlog items from the top of the product backlog until the Development Team feels it has enough work to fill the sprint. ● This is done by the Development Team asking "Can we also do this?" and adding product backlog items to the sprint backlog. ● The Development Team should keep in mind its past performance assessing its capacity for the new sprint, and use this as a guide line of how much "effort" they can complete. ● The product backlog items are broken down into tasks by the Development Team. ● Tasks on the sprint backlog are never assigned; rather, tasks are signed up for by the team members as needed according to the set priority and the Development Team member skills.
  • 12. Artifacts | Product Backlog ● This promotes self-organization of the Development Team, and developer buy-in. ● The sprint backlog is the property of the Development Team, and all included estimates are provided by the Development Team. ● Often an accompanying task board is used to see and change the state of the tasks of the current sprint, like "to do", "in progress" and "done". ● Once a Sprint Backlog is committed, no additional functionality can be added to the Sprint backlog except by the team. ● Once a Sprint has been delivered, the Product Backlog is analyzed and reprioritized if necessary, and the next set of functionality is selected for the next Sprint.
  • 13. Scrum | How it Works
  • 14. Artifacts | Sprint Once a Sprint Backlog is committed, no additional functionality can be added to the Sprint backlog except by the team. ● A time period (typically 1–4 weeks) in which development occurs on a set of backlog items that the team has committed to. ● Also commonly referred to as a Time-box or iteration. ● The increment (or potentially shippable increment, PSI) is the sum of all the Product Backlog items completed during a sprint and all previous sprints. ● At the end of a sprint, the Increment must be done according to the Scrum Team's criteria called Definition of Done (DoD). ● The increment must be in a usable condition regardless of whether the Product Owner decides to actually release it. ● The sprint burndown chart is a publicly displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference.
  • 15. Artifacts | Sprint Increment ● The increment (or potentially shippable increment, PSI) is the sum of all the Product Backlog items completed during a sprint and all previous sprints. At the end of a sprint, the Increment must be done according to the Scrum Team's criteria called Definition of Done (DoD). The increment must be in a usable condition regardless of whether the Product Owner decides to actually release it. The sprint burndown chart ● a publicly displayed chart showing remaining work in the sprint backlog. ● Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference. ● There are also other types of burndown, for example the release burndown chart that shows the amount of work left to complete the target commitment for a Product Release (normally spanning through multiple iterations) and the alternative release burndown chart, which basically does the same, but clearly shows scope changes to Release Content, by resetting the baseline.
  • 16. Scrum | How it Works
  • 17. Artifacts | Definitions Spike ● A time boxed period used to research a concept and/or create a simple prototype. Spikes can either be planned to take place in between sprints or, for larger teams, a spike might be accepted as one of many sprint delivery objectives. ● Spikes are often introduced before the delivery of large or complex product backlog items in order to secure budget, expand knowledge, and/or produce a proof of concept. ● The duration and objective(s) of a spike will be agreed between the Product Owner and Delivery Team before the start. Unlike sprint commitments, spikes may or may not deliver tangible, shippable, valuable functionality. ● For example, the objective of a spike might be to successfully reach a decision on a course of action. The spike is over when the time is up, not necessarily when the objective has been delivered.
  • 18. Artifacts | Definitions Tracer Bullet ● The tracer bullet is a spike with the current architecture, current technology set, current set of best practices which results in production quality code. It might just be a very narrow implementation of the functionality but is not throw away code. It is of production quality and the rest of the iterations can build on this code. Sprint Backlog ● Work items added to the sprint backlog at the beginning of a sprint and broken down into hours. Each task should not exceed 12 hours (or two days), but it's common for teams to insist that a task take no more than a day to finish Velocity ● The total effort a team is capable of in a sprint. The number is derived by evaluating the work (typically in user story points) completed from the last sprint's backlog items. ● The collection of historical velocity data is a guideline for assisting the team in understanding how much work they can do in a future sprint.
  • 19. Artifacts | Definitions Impediment ● Anything that prevents a team member from performing work as efficiently as possible. Sashimi ● A term used to describe one or more user stories, indicating that they are thin slices of a product feature or capability. Abnormal Termination ● The Product Owner can cancel a Sprint if necessary. ● The Product Owner may do so with input from the team, Scrum Master or management. ● For instance, management may wish to cancel a sprint if external circumstances negate the value of the sprint goal. If a sprint is abnormally terminated, the next step is to conduct a new Sprint planning meeting, where the reason for the termination is reviewed.