SSQA SCRUM 030816.ppt · Scrum / Agile Benefits The Success rate of waterfall is 11% The success rate of agile is 39%. 61% of agile teams cannot deliver so many teams are "Agile in
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
� A play in Rugby in which the two sets of forwards mass together around the ball and, with their heads down, and arms interlocked push to gain ground.
� How we define Scrum (n): � An empirical FRAMEWORK within which people can address
complex adaptive problems, while productively and creatively delivering products of the highest possible value.
� A key principle of Scrum is its recognition that during a project, 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 group’s ability
to deliver quickly and respond to emerging requirements.
� The Success rate of waterfall is 11% � The success rate of agile is 39%. � 61% of agile teams cannot deliver so many teams are "Agile in Name Only.“ Most
of them have no working product at the end of the sprint so they do not meet the second value of the Agile Manifesto.
� Even then, they reduce development costs by an average of 35%.� Research in Silicon Valley showed that if a bug was not found and fixed inside a
sprint, it took 24 times as long to find and fix three weeks later for developers building a web operating system. This finding has been replicated in Europe. So for complex products something that could be delivered in a month with Scrum would take 2 years without.
� For this reason, the CEO of Microsoft banned all test teams last year. So effectively, waterfall is banned at Microsoft. They can't compete with waterfall and neither can you.� - Jeff Sutherland, Inventor and Co-Creator of Scrum ( 8/3/2015)
Empiricism� Scrum is Founded on Empirical Process Control Theory
� Three Pillars� Transparency - Significant aspects of the process must be visible to
those responsible for the outcome. Common standards, i.e.:� A common language referring to the process must be shared by all participants; � A common definition of “Done"must be shared by those performing the work and
those accepting the work product.
� Inspection - Scrum users must frequently inspect Scrum artifacts and progress toward a goal to detect undesirable variances. Inspection should not be so frequent that it gets in the way of the work.
� 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.
Development Team� The Development Team consists of professionals who do the work of
delivering a potentially releasable increment of “Done” product at the end of each “Sprint”. Only members of the Development Team create the Increment.
� 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 of the skills as a team necessary to create a product Increment;
� Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;
� Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole;
� Development Teams do not contain sub-teams dedicated to particular domains like testing or business analysis.
� No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.
� The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.
� The Scrum Master is a servant-leader for the Scrum Team.
� The Scrum Master serves the Development Team in several ways, including:
� Coaching the development Team in self-organization and cross-functionality;
� Teaching and leading the Development Team to create high-value products;
� Removing impediments to the Development Team’s progress;
� Facilitating Scrum events as requested or needed; and,
� Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum.
� Scrum uses time-boxed events, such that every event has a maximum duration.
� This ensures an appropriate amount of time is spent
planning without allowing waste in the planning process.
� Other than the Sprint itself, which is a container for all other events, each event in Scrum is a formal opportunity to inspect and adapt something.
� These events are specifically designed to enable critical transparency and inspection. � Failure to include any of these events results in reduced transparency and is a lost
� In this part, the Development Team works to forecast the functionality that will be developed during the Sprint.
� The Product Owner presents ordered Product Backlog items to the Development Team and the entire Scrum Team collaborates on understanding the work of the Sprint.
� The inputs to this meeting:� the Product Backlog� the latest product Increment,� projected capacity of the Development Team during the Sprint,� past performance of the Development Team.
� The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team.
� Only the Development Team can assess what it can accomplish over the upcoming Sprint.
chosen?� The Development Team usually starts by designing the system and the
work needed to convert the Product Backlog into a working product Increment.
� Work may be of varying size, or estimated effort. However, enough work is planned during the Sprint Planning Meeting for the Development Team to forecast what it believes it can do in the upcoming Sprint.
� Story Time
� As a xxx, I will be able to yyy
� Planning Poker, Fist of Five, (clothing sizes)� http://wwwis.win.tue.nl/2R690/doc/agile_planning_poker.pdf
� Complexity vs time
� By the end of the Sprint Planning Meeting, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.
� A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. � During the Sprint Review, the Scrum Team and stakeholders
collaborate about what was done in the Sprint.
� Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done.
� This is an informal meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.
� Scrum’s artifacts represent work or value in various ways that are useful in providing transparency and opportunities for inspection and adaptation. Artifacts defined by Scrum are specifically designed to maximize transparency of key information needed to ensure Scrum Teams are successful in delivering a “Done” Increment.
� 3 Principal Artifacts� Product Backlog� Sprint Backlog� Increments
� Monitoring Progress� Release Burn down� Product Burn down
Information Radiator� An information radiator is a large, highly visible display used by
software development teams to track progress.
� The term was first coined by Alistair Cockburn, one of the judges for the Ultimate Wallboard contest, in his book as follows:
� “An Information radiator is a display posted in a place where people can see it as they work or walk by. It shows readers information they care about without having to ask anyone a question. This means more communication with fewer interruptions."
� It is large and easily visible to the casual, interested observer
� It is understood at a glance
� It changes periodically, so that it is worth visiting
� It is easily kept up to date
27
Product Backlog
� The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to 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, and estimate.
� A The Product Backlog evolves as the product and the environment in which it will be used evolves.
� Story points, not time ( important so I mention it again)
� The Product Backlog is often written in story format, and ordered by value, risk, priority, and necessity.
� Top-ordered Product Backlog items drive immediate development activities.
� The higher the order, the more a Product Backlog item has been considered, and the more consensus exists regarding it and its value.
� Higher ordered Product Backlog items are clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail.
� Product Backlog items that will occupy the Development Team for the upcoming Sprint are fine-grained, having been decomposed ( stories) so that any one item can be “Done” within the Sprint time-box.
� Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “ready” or “actionable” for selection in a Sprint Planning Meeting.
� 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.
� The Sprint Backlog defines the work ( stories, tasks) the Development Team will perform to turn Product Backlog items into a “Done” Increment.
� The Sprint Backlog makes visible all of the work that the Development Team identifies as necessary to meet the Sprint Goal.
Burn Down� A burn-down chart tracks how much work remains on your project
and whether you’ll hit your deadline.
� The vertical axis measures work done, and projects work remaining
� The horizontal axis marks your iterations
� After each iteration you mark your progress on the chart and you can project forward to see whether or not you’ll hit your target end date (assuming no changes)
� Initial plan was 14 points. On day 3, a complexity was uncovered, and 2 additional points were added. On day 5, it was determined to drop the story ( return to backlog), and reduce 4 points.
Burn Up� A burn-up chart tracks how much work is done.
� It shows more information than a burn-down chart because it also has a line showing how much work is in the project as whole (the scope as workload), and this can change.
� It tracks what has been done and what’s remaining.
� When the Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means.
� Members must have a shared understanding of what it means for work to be complete, to ensure transparency.
� This is the “Definition of Done” for the Scrum Team and is used to assess when work is complete on the product Increment.
� The same definition guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning Meeting.
� The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current Definition of “Done.”
� As Scrum Teams mature, it is expected that their Definition of “Done” will expand to include more stringent criteria for higher quality.
Done – DoD Dilemma� DoD Dilema -Different DoD for different teams
� For development some code is considered done when it has been written, compiled, debugged, unit tested, checked-in in a common repository, integrated in a build, verified by a build verification tool and documented using an automatic documentation generator.
� For automation test cases are considered done when the corresponding automated testing scripts have been coded, unit tested and ran against a build.
� For quality engineering done means that the user stories received on a specific build have been tested by running testing cycles, encountered bugs have been reported using a bug tracking tool, fixes provided have been validated and the associated trackers have been closed. In consequence, test cycles include both manual and automated test case execution.
� For project managers done means that the sprint has ended and the user stories have been completed (not necessarily accepted by QE) and the schedule hours burned. Moreover, for managers done usually means that there’s something−anything−that can be presented to the stakeholders in a demo.
� Development DoD is not enough because code was produced but not tested, at least not tested from the users perspective. Crucial tests like functionality, usability, performance, scalability and stress are still pending. Without passing all those tests, at least to a certain level, the product is simply not good enough for being shipped. A big temptation is to consider that in early stages of the product, the code is not required to pass all tests or there’s no need to test it at all. This of course violates the very definition / concept of a potentially shippable product.
� Automation DoD is not good enough either, because it only covers code that has been written to test code, no bugs discovered, validated, retested or closed. It’s very true that automated test cases save many man hours of manual testing, but it should only be used as a tool that helps Quality Engineers in their work and not as a milestone that if reached qualifies the product for release.
� Project Manager’s DoD it’s focused on metrics and high level information. The biggest risk for Project Managers is to look at the wrong metrics and try to put a product out of the door when it’s not complete or stable enough. Avoiding biased perceptions that come from information collected from only one group of engineers in a team is the key for telling if the product is ready or not to go into production.
� Coming from a quality background, Quality Engineering DoD in my opinion, is the initial definition that contributes the most to the goal of having a potentially shippable product; the reason in simple, QE should be the last check point for telling if the implemented user stories are good enough for being considered as part of a potentially shippable product.
� Potential additions can include documentation to be provided is available and has been reviewed for technical accuracy.
� Another is that automated test cases have been checked for effectiveness and real contribution to bug detection and validation.
� Done means that the user stories received on a specific build have been included andtested by running testing cycles, encountered bugs have been reported using a bug tracking tool, fixes provided have been validated and the associated trackers have been closed.
� In consequence, test cycles include both manual and automated test case execution.
� It is evident that we need a DoD that can work for the whole team helping it to remain focused in the right direction and serving at the same time as a true enabler for the potentially shippable product concept.
� Start simple, and enhance as skills and capability of Team matures.
� An empirical FRAMEWORK within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
� A key principle of Scrum is its recognition that during a project, 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 group’s ability to deliver quickly and respond to emerging requirements.
� But, it’s a FRAMEWORK, not a total solution
� Design
� Unit vs Integration
� Additional components to complete for the total solution