SSQA SCRUM 030816.ppt · Scrum / Agile Benefits The Success rate of waterfall is 11% The success...

3/9/2016

1

Burn Up and Burn Down

An Overview of Scrum

Neal Kuhn

Business Systems Architects, LLC

[email protected]

Scrum Agenda (1) � Setup (5)

� At the end of this segment, the project and slides are set up

� Agenda (5)� At the end of this section, the team will understand the agenda of this presentation

� Scrum Definition (5)� At the end of this section, the team will understand the name and that Scrum is a framework

� Roles (10)

� At the end of this section, the team will understand the roles in Scrum

� Development Team

� Product Owner

� Scrum Master

� Events/ceremonies (10)� At the end of this section, the team will understand events in Scrum (Sprints)

� Sprint

� Sprint Planning

� Daily Scrum

� Sprint Review

� Sprint Retrospective

© 2016 Neal Kuhn All rights reserved.

3/9/2016

2

Scrum Agenda (2)

� Artifacts (15)� At the end of this section, the team will understand the artifacts used in Scrum

� Product Backlog

� Sprint Backlog

� Product Increment

� Release and Sprint Burndown

� Monitoring Progress

� Burn Down vs. Burn Up

� Done (10)� At the end of this section, the team will understand the concept of Done

� Definition of Done


SCRUM� Origin of Scrum

� 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.

� (Agile value 2)© 2016 Neal Kuhn All rights reserved.

3/9/2016

3

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 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.


3/9/2016

4

SCRUM ROLES

� Three core roles and a range of ancillary roles� core roles are often referred to as pigs and ancillary roles as

chickens

� Pigs:

� Development ( or Scrum) Team

� Product Owner

� Scrum Master

� Everyone else is a chicken


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.


3/9/2016

5

Development Team ( 2)

� 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.


Product Owner

� The Product Owner is responsible for maximizing the value of the product and the work of the Development Team.

� 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;

� Ensuring 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; and,

� Ensuring the Development Team understands items in the Product Backlog to the level needed.


3/9/2016

6

Product Owner (2)

� The Product Owner is one person, not a committee.

� For the Product Owner to succeed, the entire organization must respect his or her decisions.

� The Product Owner’s decisions are visible in the content and ordering of the Product Backlog.


Scrum Master

� 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,

� Coaching the Development Team


3/9/2016

7

Scrum Master - (2)

� 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.

� The Scrum Master serves the Product Owner in several ways, including:

� Helping find techniques for effective Product Backlog management;

� Clearly communicating vision, goals, and Product Backlog items to the Development Team;

� Teaching the Scrum Team to create clear and concise Product Backlog items;

� Understanding long-term product planning in an empirical environment; .


SCRUM EVENTS/”Ceremonies”

� 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

opportunity to inspect and adapt.


3/9/2016

8

Scrum Events / Time Boxes

� Sprint

� Sprint Planning Meeting

� Developmental Work

� Daily Scrum / Standup Meeting

� Sprint Review

� Sprint Retrospectives


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 Meeting, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.

� During the Sprint:

� No changes are made that would affect the Sprint Goal;

� Development Team composition remains constant;

� Quality goals do not decrease; and,

� Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.


3/9/2016

9

Sprint Time Length

� Each Sprint may be considered a project with no more than a one-month horizon.

� Like projects, Sprints are used to accomplish something.

� Each Sprint has a definition of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product.

� Sprints are limited to one calendar month.

� When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase.

� Sprints enable predictability by ensuring inspection and adaptation of progress toward a goal at least every calendar month.

� Sprints also limit risk to one calendar month of cost.


Sprint Planning Meeting� The work to be performed in the Sprint is planned at the Sprint Planning

Meeting.

� This plan is created by the collaborative work of the entire Scrum Team.

� The Sprint Planning Meeting is time-boxed to eight hours for a one-month Sprint. For shorter Sprints, the event is proportionately shorter.

� For example, two-week Sprints have four-hour Sprint Planning Meetings.

� The Sprint Planning Meeting consists of two parts, each one being a time-box of one half of the Sprint Planning Meeting duration.

� The two parts of the Sprint Planning Meeting answer the following questions, respectively:

� What will be delivered in the Increment resulting from the upcoming Sprint?

� How will the work needed to deliver the Increment be achieved?


3/9/2016

10

Sprint – What will be

done/ delivered?

� 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.


Sprint – How will the work be

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.


3/9/2016

11

Daily Scrum / Stand Up Meeting� The Daily Scrum is a 15-minute time-boxed event for the Development

Team to synchronize activities and create a plan for the next 24 hours.

� This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one.

� The Daily Scrum is held at the same time and place each day to reduce complexity.

� During the meeting, each Development Team member explains:

� What has been accomplished since the last meeting?

� What will be done before the next meeting?

� What obstacles are in the way?


Why Daily Scrum?

� Transparency – high visibility of progress and accountability

� Adaptation – catch problems early and allow for rapid response / change

� THIS IS NOT A STATUS MEETING TO COLLECT INFORMATION.

� It is a meeting in which every team member make commitments to each other.


3/9/2016

12

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 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.


Sprint Review (2)

� The Sprint Review includes the following elements: � The Development Team demonstrates the work that it has “Done” and

answers questions about the Increment;

� The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;

� The Product Owner identifies what has been “Done” and what has not been “Done”;

� The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates based on progress to date; and,

� The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning Meetings.


3/9/2016

13

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 Meeting.

� 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.

� During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by adapting the Definition of “Done” as appropriate.


Scrum Artifacts

� 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

� Story Points, not time

� (Information Radiators)


3/9/2016

14

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)


3/9/2016

15

Product Backlog (2)

� 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.


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.

� 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.


3/9/2016

16

Monitoring Progress

� At any point in time in a Sprint, the total work remaining in the Sprint Backlog items can be summed.

� The Development Team tracks this total work remaining at least for every Daily Scrum and projects the likelihood of achieving the Sprint Goal.

� By tracking the remaining work throughout the Sprint, the Development Team can manage its progress.

� Scrum does not consider the time spent working on Sprint Backlog Items. The work remaining and date are the only variables of interest.


Monitoring Progress (2)

� Scrum does not consider the time spent working on Sprint Backlog Items. The work remaining and date are the only variables of interest.

� Terms / definitions

� Scope / Target� Beware target fixation

� Velocity

� Efficiency

� Variance

� Efficiency / Effectiveness� waterfall is efficient — agility is effective

� Release Burn down/burn up

� Product Burn down/burn up


3/9/2016

17

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)


Burn Down Chart

© 2016 Neal Kuhn All rights reserved. 34

3/9/2016

18

Burn Down Chart – positive variance


Burn Down Chart – negative variance


3/9/2016

19

Burn Down Chart - Question� What happens if complexity/task is added or a

story/task is dropped?

� Scope has been changed.

� How do I indicate in the burn down?

� Modify initial scope of work so line is continuous?

� Negates planning and all tracking to date

� Stair step line to indicate change and notate?

� More accurate, but a tracking nightmare


Burn Down Chart - Example� Scenario:

� 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.

� Burndown to date:


Day BD/Hist BD/TBD Delta New TBD

Day 1 1 13

Day 2 1 12

Day 3 2 10 +2 12

Day 4 1 11

Day 5 1 10 -4 6

Day 6 1 5

Use initial velocity

3/9/2016

20

Burn Down Chart – (changes)


Burn Down Chart – (changes)


?

3/9/2016

21

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.

� More adaptable to change.


Burn Up Chart


3/9/2016

22

Burn Up Chart – positive variance


Burn Up Chart


3/9/2016

23

Burn Up Chart – (change 1)


Burn Up Chart – (change 2)


3/9/2016

24

Definition of Done

� 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.


3/9/2016

25

Done – DoD Dilemma (2)� DoD Holes

� 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.


Done – A starting Definition� Definition of Done

� 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.


3/9/2016

26

DoD - First Pass

� 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.


DOD - Summary

� 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.


3/9/2016

27

Scrum Summary

� Definition of 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.

� But, it’s a FRAMEWORK, not a total solution

� Design

� Unit vs Integration

� Additional components to complete for the total solution


I’m Done

Thanks

[email protected]

3/9/2016

28

Background - Agile Manifesto� The Agile Manifesto is based on twelve principles:[15]

� Customer satisfaction by early and continuous delivery of valuable software

� Welcome changing requirements, even in late development

� Working software is delivered frequently (weeks rather than months)

� Close, daily cooperation between business people and developers

� Projects are built around motivated individuals, who should be trusted

� Face-to-face conversation is the best form of communication (co-location)

� Working software is the principal measure of progress

� Sustainable development, able to maintain a constant pace

� Continuous attention to technical excellence and good design

� Simplicity—the art of maximizing the amount of work not done—is essential

� Best architectures, requirements, and designs emerge from self-organizing teams

� Regularly, the team reflects on how to become more effective, and adjusts accordingly

© 2016 Neal Kuhn All rights reserved.55

SSQA SCRUM 030816.ppt · Scrum / Agile Benefits The Success rate of waterfall is 11% The success...

Documents

Transcript of SSQA SCRUM 030816.ppt · Scrum / Agile Benefits The Success rate of waterfall is 11% The success...