Scrum in IT Industry Part 2
- 1. Scrum in IT Industry Part 2 -Jayesh Patil
- 3. Scrum is an agile way to manage a project, usually software development. Agile software development with Scrum is often perceived as a methodology; but rather than viewing Scrum as methodology, think of it as a framework for managing a process. A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value .
- 4. Scrum Theory Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk.
- 6. Scrum Pillars contd…. Transparency : Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen. Inspection : Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances. Their inspection should not be so frequent that inspection gets in the way Adaptation : If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation. Scrum
- 7. Scrum Roles - The Scrum Team Within the Scrum Framework three roles are defined: Each of these roles has a defined set of responsibilities and only if they fulfill these responsibilities, closely interact and work together they can finish a project successfully.
- 8. The Product Owner The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team The Product Owner is the sole person responsible for managing the Product Backlog. 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. The Product Owner may do the above work, or have the Development Team do it. The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner. The entire organization must respect his or her decisions.
- 9. The Development Team The Development Team consists of professionals who do the work of delivering a potentially releasable Increment. Development Teams have the following characteristics: • They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality; • Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment; • Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person; • Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and, • Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.
- 10. 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. The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.
- 11. Characteristics of a Scrum Team Scrum Teams always have the following characteristics: Team members share the same norms and rules The Scrum team as a whole is accountable for the delivery The Scrum Team is empowered It is working as autonomous as it is possible The Scrum Team is self organizing The skills within the Scrum team are balanced A Scrum Team is small and has no sub-teams The people within the Scrum Team work full time in the team People are collocated
- 12. SCRUM Quick flash 3 Roles: 1)Product Owner 2) Scrum Master 3) Scrum Team/Dev Team 3Pillars : 1) Transparency 2) Inspection 3) Adaptation
- 13. Rules & Norms The environment defines some of the norms the teams have to follow, but some rules and norms are developed during the Norming phase. This set of common rules is quite important. Otherwise the team members would have to constantly waste valuable time to switch between different value systems and rule sets. Examples for such norms and rules are: 1) Time and location of the Daily Scrum Meeting 2)The Definition Of Done (DoD) used to decide if work is finished or not coding guidelines 3)Tools to use
- 14. Accountability The Scrum Team as a whole is responsible to deliver the committed delivery in time and with the defined quality. A good result or a failure is never attributed to a single team member but always the result of the Scrum Team.
- 15. Empowerment & Self organization The Scrum Team has to be empowered to definewhat it will commit to deliver at the end of the sprint how the expected results have to be broken down into tasks who will perform the task and in which order they are performed Only if the Scrum Team is empowered to decide these things it will work with the highest possible motivation and performance.
- 16. Balanced set of skill Individuals within the Scrum Team will most certainly have specialized skills and focus. However to achieve best possible performance it would be optimal to have a balanced set of skills. Only then the Scrum Team will be able to deal with the ever-changing challenges and can act as autonomous as it is possible. On one hand this means that a Scrum Team should be multidisciplinary (developers, tester, architects etc) right from the beginning. On the other hand this also means that each team member should learn a little bit of each other's specialization, e.g. a if required to finally reach the committed goal a developer should also perform or write tests. As a consequence this also means that within the Scrum Framework it is not differentiated between e.g. "tester" and "architect", they all share the same title "Scrum Team Member" even if the primary skill is not to develop production code.
- 17. Size of the Scrum Team Scrum Teams are small. The ideal size is 3-9 . If there are more people the communication overhead gets too large and the team should be split into multiple Scrum Teams. These Scrum Teams should be coordinated and communicate with each other but otherwise work independently.
- 18. Collocation To minimize unnecessary communication overhead each Scrum Team should be collocated. If work has to be spread over multiple locations, independent Scrum Teams should be created.
- 19. Responsibilities of the Scrum Team The Scrum Team and each of the team members has certain responsibilities which have to be fulfilled They have to breakdown the requirements, create task, estimate and distribute them. In other words this means that they have to create the Sprint Backlog. They have to perform the short Daily Sprint Meeting. They have to ensure that at the end of the Sprint potentially shippable functionality is delivered. They have to update the status and the remaining efforts for their tasks to allow creation of a Sprint Burndown Diagram.
- 20. Scrum Values 1) Commitment.... 2) Focus. ... 3) Openness. ... 4) Respect. ... 5) Courage.
- 21. Scrum Artifacts Scrum’s artifacts represent work or value to provide transparency and opportunities for inspection and adaptation. 1) Product Backlog 2) Sprint Backlog 3) Increment
- 22. Product Backlog The Product Backlog is an ordered list of everything that is known to be needed in the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering. The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when “Done.” A Product Backlog is never complete. Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product. A Product Backlog attribute that groups items may then be employed.
- 23. Sprint Backlog The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. 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 makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal. The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint.
- 24. Product Increment The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.” The increment is a step toward a vision or goal. The increment must be in useable condition regardless of whether the Product Owner decides to release it.
- 25. Scrum Ceremonies/Events Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum. All events are time-boxed events, such that every event has a maximum duration. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened. The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process.
- 26. The Sprint The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint. Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.
- 27. Cancelling a Sprint A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master. A Sprint would be cancelled if the Sprint Goal becomes obsolete. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. But, due to the short duration of Sprints, cancellation rarely makes sense.
- 28. Sprint Planning There are two defined artifacts that result from a sprint planning meeting: A sprint goal A sprint backlog Sprint Goal : A sprint goal is a theme for the sprint ,as the essential focus of the sprint. Product owner shall share the sprint Goal ,created during the sprint planning . Sprint Planning is a collaborative efforts involving a scrum master ,who facilitates the meeting ,a product owner ,who clarifies the details of the product backlog item and their respective acceptance criteria ,and the entire agile team.who defines the work and effort necessary to meet their sprint commitment. It’s the 1st meeting to Kick off the sprint . Duration: 2hrs/ week of sprint Who will attend:In Scrum, the sprint planning meeting is attended by the product owner, ScrumMaster and the entire Scrum team. Outside stakeholders may attend by invitation of the team, although this is rare in most companies. During the sprint planning meeting, the product owner describes the highest priority features to the team.
- 30. Sprint Planning meeting The Sprint Planning Meeting is typically broken into two parts. Part 1: Part one of the sprint planning meeting is a review of the product backlog items the Product Owner will ask the team to forecast and deliver. This is the time for the product owner to describe what she wants to see built for the next sprint. During this part of the meeting, it is not uncommon for the team to banter back and forth with the product owner, asking clarifying questions and driving away ambiguity. sprint planning part one, the team will select a sprint goal: a one-sentence description of the overall outcome of the sprint Part 2: During part two of the sprint planning meeting, the team decides how the work will be built. In this meeting the team will begin decomposing the product backlog items into work tasks and estimating these in hours. The product owner must be available during this meeting but does not have to be in the room. The output of the second planning meeting will be the Sprint Backlog.
- 31. Daily Scrum The Daily Scrum is held every day of the Sprint. The Daily Scrum is a 15-minute time-boxed event for the Development Team. • What did I do yesterday • What will I do today • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal? The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.
- 32. Sprint Review • A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. • During review meeting, the Scrum team shows what they accomplished during the sprint. Typically this takes the form of a demo of the new features. • The sprint review meeting is intentionally kept very informal, typically with rules forbidding the use of PowerPoint slides and allowing no more than two hours of preparation time for the meeting. • Participants: the product owner, the Scrum team, the ScrumMaster, management, customers and developers from other projects. • Duration: 1hrs/week of sprint
- 33. Sprint Retrospective • The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. • The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. • Duration: 3hrs /month sprint • The Scrum Master ensures that the meeting is positive and productive. The Scrum Master teaches all to keep it within the time-box. • The purpose of the Sprint Retrospective is to: • • Inspect how the last Sprint went with regards to people, relationships, process, and tools; • • Identify and order the major items that went well and potential improvements; and, • • Create a plan for implementing improvements to the way the Scrum Team does its work. • By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself.
- 34. Velocity The Velocity is a measure of the amount of work a team can tackle during a single sprint and is the key metric in Scrum . The estimate is based on the past records/performance of the team. It is calculated by averaging the total amount of story points completed over the number of sprints completed . Eg: If a team has completed 3 sprints having 65,70,100 sprint points respectively ,then the velocity at that point is 80 story points .
- 35. SCRUM Quick flash 3 Roles: 1)Product Owner 2) Scrum Master 3) Scrum Team/Dev Team 4 Cermonies/Events: a) Sprint Planning b) Daily Scrum c) Sprint Review d) Sprint retrospective 3 Artifacts : 1)Product Backlog 2)Sprint Backlog 3)Product Increment 3Pillars : 1) Transparency 2) Inspection 3) Adaptation 5 Values : 1) Openness 2) commitment 3)Courage 4) Focus 5) Respect
- 36. User Stories User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template: As a < type of user >, I want < some goal > so that < some reason >.
- 37. Estimation The Scrum Estimation of User Stories is in terms of the degree of difficulty for each of the User Stories. Relative estimation is done Here are 7 agile estimation techniques Planning Poker. T-Shirt Sizes. ... Dot Voting. ... The Bucket System. ... Large/Uncertain/Small. ... Affinity Mapping. ... Ordering method.
- 38. Estimation Techniques The 7 agile estimation techniques 1) Planning Poker. 2) T-Shirt Sizes. ... 3) Dot Voting. ... 4) The Bucket System. ... 5) Large/Uncertain/Small. ... 6) Affinity Mapping. ... 7) Ordering method.
- 39. Planning Poker Planning Poker is an agile estimating and planning technique that is consensus based. Most teams will hold a Planning Poker session shortly after an initial product backlog is written. Planning Poker can be used with story points, ideal days, or any other estimating unit. Planning Poker leads to better estimates is because it brings together multiple expert opinions. Story Points are used as the measurement, Fibonicc series is generally used .
- 40. Story Points The story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work. In story sizing ,team does comparative analysis between all of the stories for the project .
- 41. Story point Vs Time based/Man hours estimation Story Point estimation 1)The Points are estimated based on the efforts and complexity. 2)No correlation with skills and experience of the estimator . 3)Universal measurement across the whole team & not depend on who’s implementing the story . Time Based estimation 1) The approach to measure the amount of work that can be completed by one person in 1hrs. 2)It Underestimates the obstacles they might face and consider only the best case scenario. 3) The work might be estimated and completed by different developers.
- 42. Fibonacci Series for story points The fibonacci sequence is used by Scrum teams for story point estimates – 1, 2, 3, 5, 8, 13, 21, and so on. Teams use this sequence, rather than a linear 1 – 10 as it forces them to provide a relative estimate. Easier to ask ‘is that a 5 or an 8?’ than ‘is that a 6 or a 7?’. The reason for using the Fibonacci sequence is to reflect the inherent uncertainty in estimating larger items. The information that we obtain out of estimation grows much slower than the precision of estimation. In fact it grows as a logarithmic function. This is the reason for the higher uncertainty for larger items. because they grow at about the same rate at which we humans can perceive meaningful changes in magnitude
- 43. The Cone of Uncertainty describes the evolution of the amount of uncertainty during a project. Uncertainty not only decreases over time passing, but it also diminishes its impact by risk management, specifically by decision-making. At the beginning of a project, comparatively little is known about the product or work results, and so estimates are subject to large uncertainty. As more research and development is done, more information is learned about the project, and the uncertainty then tends to decrease, reaching 0% when all residual risk has been terminated or transferred. This usually happens by the end of the project i.e. by transferring the responsibilities to a separate maintenance group. The term Cone of Uncertainty is used in software development where the technical and business environments change very rapidly. The cone of uncertainty
- 45. T-Shirt Sizing estimate A form of estimation that is often, although not exclusively, used to size product backlog items T-shirt sizing is a way to practice relative sizing. Commonly used with T-shirt sizes: extra small, small, medium, large, extra large, etc.
- 46. A storyboard is a graphic organizer that provides the viewer with a high- level view of a project. In Agile software development, a storyboard can help developers quickly get a sense of what work still needs to be completed. In Scrum software development, the storyboard may be called a task board. Story Board / Task Board-M&C
- 47. Burn Down Chart-M&C A burn down chart is a graphical representation of work left to do versus time. The outstanding work (or backlog) is often on the vertical axis, with time along the horizontal. it is a run chart of outstanding work. Progress on a Scrum project can be tracked by means of a release burndown chart. It is useful for predicting when all of the work will be completed. The horizontal axis of the sprint burndown chart shows the sprints; the vertical axis shows the amount of work remaining at the start of each sprint.
- 48. Burn Up Chart-M&C Burn up chart shows how much work has been completed. It is an effective tool for communicating to the project stakeholders and clients how the extra feature requests they are asking for will affect the deadline, and at the same time for reassuring them that good progress is being made. In the simplest form of burn up chart there are two lines on the chart: 1) A total work line (the project scope line) 2) A work completed line Burn up charts are slightly more complex to interpret than burn down charts, so will often require some short explanation to people not familiar with them.
- 49. Technical debt- Quality Technical debt (also known as design debt or code debt) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer. Code that is not quite right may include many types of issues. These issues may be related to architecture, structure, duplication, test coverage, comments and documentation, potential bugs, complexity, code smells, coding practices and style. All these types of issues incur technical debt because they have a negative impact on productivity.
- 50. SCRUM Quick flash 3 Roles: 1)Product Owner 2) Scrum Master 3) Scrum Team/Dev Team 4 Cermonies/Events: a) Sprint Planning b) Daily Scrum c) Sprint Review d) Sprint retrospective 3 Artifacts : 1)Product Backlog 2)Sprint Backlog 3)Product Increment 3Pillars : 1) Transparency 2) Inspection 3) Adaptation 5 Values : 1) Openness 2) commitment 3)Courage 4) Focus 5) Respect
- 51. MoSCoW Analysis – Prioritization of the Product Backlog The MoSCoW method is a prioritization technique used in management, business analysis, project management, and software development to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement. MosCoW is a way determining the importance of requirements for a project
- 52. Happy Scrumming