TestmanagementChanging the world one bug after amother…

  • Scrum Framework

    Open or Close
    Scrum
    Scrum is an agile management framework for developing software.

    The Agile Manifesto (Beck et al. 2001) places people in the center of software development.
    Scrum embodies this framework. It is neither technology nor tool oriented. The Agile Manifesto formulates optimal customer satisfaction and added value as the goal of its software development.

    Scrum is a framework for a continual product development and not a project management method.

    The role of Project Manager does not exist in Scrum.

    An excellent overview of Scrum is detailed in the diagram below by Mahud Laulin via Scrum Alliance:
    Scrum Übersicht

  • Small Projects

    Open or Close

    • Roles in Scrum

      Open or Close
      Scrum framework includes 3 Roles (Scrum Team): Product Owner, Scrum Master, and Development Team.

      For larger organizations requiring more teams, there are special frameworks with further roles provided.
      Product Owner (PO)
      • is responsible for the product’s additional benefits (Mehrwert) and the team‘s delivered product increments
      • maintains the product backlog
      • is responsible for the product development
      • is responsible for the reception, maintenance and prioritization of all requirements
      • creates the release plan and release reports
      • should spend approx. one hour working together with the team, for example, after the Daily Scrum
      Scrum Master (SM)

      • makes sure that Scrum is understood and used properly, efficiently, and delivers the highest quality product
      • supports the PO in building the product backlog
      • secures the required test environment
      • protects the team from being assigned to non related tasks and from reducing the team count in an ongoing Sprint
      • functions as Servant-Leader (dienende Führungskraft)
      • useful skills: moderation techniques, coaching, and experience in software development
      • eliminates impediments
      • does not allocate tasks to the team
      • is generally not an integral part of the development team


      Development Team (Team)

      • at the end of every Sprint, they produce a finished product increment
      • only the PO may instruct the team
      • only the PO instructs the team to implement the requirements from the Product Backlog
      • the team consists of developers (testers, administrators, and other specialists)
      • the team consists of 3 to 9 members
      • the ideal team member is a specialist as well as a generalist


      Stakeholder

      • a Stakeholder is any role outside of Scrum
      • Stakeholders include personnel, for example, from: marketing, sales, service, IT, and customers/users

    • Reports, User Stories, Definitions, etc.

      Open or Close
      Requirement Workshop
      Refining high priority requirements through Requirement Workshops with the PO and team before the first Sprint begins.

      Story Cards
      Requirements which are written on index cards.

      Team Capacity
      The net team capacity is around 20-35 % under the gross capacity.

      Expenditures Calculated
      Estimates of expenditures calculated by Story Points, for example: Fibonacci Function.

      Bildschirmfoto 2016-02-08 um 19.37.41

      It yields the following points
      • 0 (no expenditures),
      • 1 (very small expenditures)
      • 2 (small expenditures)
      • 3 (moderate expenditures)
      • 5 (high expenditures)
      • 8 (very high expenditures)
      • 13 (enormous expenditures)

      The estimate calculations will usually be made before the first Sprint.

      The results will be reflected in the Product Backlog.
      Also, during a Sprint, estimate calculations will be made.
      The estimates are made by the Team.
      A Planning Poker can also be used for the estimates.

      Planning Poker
      This is a method Scrum uses to estimate expenditures by using playing cards on which story points are printed.
      The PO presents the various User Stories to the Team for their evaluation and agreement, until there is consensus.

      The following illustration of the Planning Poker playing cards originated from ITEMIS AG.
      Release Plan
      The Release Plan consists of a number of necessary Sprints and the sequence of the requirement realisation from the Product Backlog.
      The PO provides this plan.

      Release Burndown Report
      This plan is updated at the end of every Sprint.
      It is the sum of expenditures in the Product Backlog at the end of every Sprint. The ideal Burndown Line reflects no absences. Through this comparison of ideal progress to real progress, one can see the real progress development.

      Velocity Report
      Velocity is necessary for the Release Plan. Velocity is the sum of all the expenditures at the end of the Sprints from the PO’s released work results.
      Partially completed or defective work results are not included.
      If, at the beginning of the first Sprint, no Release Plan is provided, the Velocity is estimated empirically, for example, starting at a maximum velocity of 20 points. Experience shows that in the first Sprint, usually a velocity of 60 % will be achieved. In the Sprints which follow, the velocity will increase.

      End-of-Sprint Report
      Documentation, like many of the planned requirements, is released by the PO.
      The report consists of the essential basic data of the Sprint.
      Created by the PO in the Sprint Review, or thereafter.
      The report is, once again, input for the Release-Burndown and Velocity Reports, as well as the Release Plan.

      Impediments Chart
      Provided by the SM in the Daily Scrum. From the Impediment Chart, many impediments to the Sprint progress can be avoided.
      Definition of Done (DoD)
      The Definition of Done defines when a task has been completed.
      The Scrum team determines these conditions.
      A resolved User Story is completed (DoD).
      Every team defines its own definition of DoD.
      At the end of a Sprint, the Acceptance Criteria and the DoD are necessary in determining whether the Product Backlog item will be accepted as completed.
      DoD is continually being optimized.
      DoD contains, in addition, quality criteria and non-functional requirements.

      Taskboard/Kanbanboard
      A task board serves the visualisation of the Sprint Backlogs in at least four columns.
      Column 1: Requirements from the Product Backlog
      Column 2: All „To Do“ tasks
      Column 3: All tasks for development and testing
      Column 4: All tasks in this status done
      A Taskboard is not a Kanbanboard. A Taskboard is for teams which plan their work in Sprints. Kanbanboards have no Product Backlog.
      In the Daily Scrum, the Taskboard is updated.
      Tasks which are not completed in one day should be tagged.
      Ideally the Team always works on only one User Story at a time.
      User Stories, Acceptance Criteria and Acceptance Tests
      User Stories describe the requirements from the point of view of the user in everyday language.
      A User Story always describes the desired product capabilities and their benefits.
      The design of the User Stories is made in the Sprint Planning. Here the User Stories and the related tasks are created. A task should be completed in one working day.
      The PO formulates the Acceptance Criteria, which is then approved by the customer, and this information is added to the User Story.
      In the Acceptance Test Case, a description of how the properties are to be tested should be given.
      Acceptance Criteria should also be provided for EPICS       (large User Stories)

      Characteristics of good User Stories (Acronym INVEST):
      IIndependentUser Stories should be independent from each other
      NNegotiableUser Stories should be negotiable
      VValuableUser Stories should have value to the customer
      EEstimatableUser Stories should be estimable
      SSmall User Stories should be small
      TTestableUser Stories should be testable
      Burndown Chart
      The Burndown Chart serves as a visualisation of the work realised and the work to be done.
      The Development Team updates the Sprint Burndown in the Daily Scrum.
      The following Burndown Chart displays 5 Sprints in which each Sprint has exactly 20 Story Points of completed work. Therefore exactly 100 Story Points on the ideal line are completed.
      If the velocity trend is below the ideal line, the following Sprints must increase the Velocity in order to reach the desired goal.

    • Scrum Events

      Open or Close
      In Scrum terminology, meetings are referred to as Scrum Events.
      These have Time Boxes.
      Sprint
      A Sprint is a segment of work in which a product increment is produced.
      The product development proceeds in cycles/iterations for a maximum of 4 weeks.
      Sprints should always have the same duration.
      A Sprint is finished when the allocated time is up.
      Sprints follow directly in sequence.
      If the PO must cancel an actual Sprint, it ends with a Sprint Retrospective.

      Exploration Sprint
      In innovative and complex Scrum projects, explorative Sprints can be conducted in advance in order to gain the necessary knowledge for the prototype.
      There will be no deliverable increments made. Exploration Sprints should not take longer than one week.

      Release Sprint
      Release Sprints achieve no value from a customer point of view. They can, however, become necessary, for example, if a client specific configuration must be implemented.
      Sprint Planning (Part 1 and 2)
      Duration: Max. 2 hours for every Sprint week, max. 8 hours for 4 weekly Sprints.

      Part 1
      The PO provides a preselection of the prioritized and intended requirements.
      The Product Backlog should be prepared for Product Backlog Refinement for the next Sprint.
      The Team identifies the necessary tasks, defines the expenditures and the requirements to be implemented.
      The PO and Team agree on the Definition of Done.
      The SM moderates the Sprint Planning.

      Part 2
      Here the Team provides a realistic Sprint Backlog on the basis of Part 1 and the tasks of implementation.

      Daily Scrum
      In the Daily Scrum, the selection of activities will be coordinated.
      In the Daily Scrum, problems will not be solved - it is simply an exchange of information. The answers to questions should follow at the end of this Daily Scrum.
      The PO and SM can be present, but are not active participants.
      Every Team member reports at the beginning of each work day about the work completed the day before, the tasks planned for that day, and identifies necessary improvements to be made.
      Duration: Max. 15 min.

      Sprint Review
      At the end of the Sprint and before the Retrospective.
      Presentations of the produced Product Increments, receiving feedback, especially from Stakeholders.
      The Team presents its results.
      The PO decides about the development of new functions.
      Duration: Max. 1 hour for every Sprint week.
      Members: PO, SM, Team, and optional Stakeholders.

      Sprint Retrospektive
      Directly at the end of the Sprint Review.
      The entire Scrum Team discusses the approach, the methods and teamwork.
      Agreement on the improvements.
      Duration: 45 min. per week, in a 4 week Sprint of 3 hours.
      Members: PO, SM, Team, and no optional Stakeholders.

      Product Backlog Refinement (Backlog Grooming/Estimation Meeting)
      This is an ongoing process, which should not take more that 10 % of the Development Team’s time.
      PO, Team, and selected Stakeholders participate, so that the entries can be worked on, estimated, and the Releases planned.

    • Artifacts

      Open or Close
      Scrum defines 3 Artifacts.
      Product Backlog
      Maintained by PO.
      List of all priority Requirements and Work Results, which are necessary for the future product.
      During the Sprint process, the list becomes more detailed and refined.
      Scrum recognises no Change Request Procedure.
      The Product Backlog
      • grows iteratively/incrementally
      • contains the Acceptance Criteria and the expenditures of the Requirements
      • should have enough Requirements at the start of the project for the first 2-3 Sprints
      • prioritised according to risks. This prioritisation guides the PO and Team together
      • User Stories are included, not the complex Use Cases

      Sprint Backlog
      Selected Product Backlog items for actual Sprint.
      Prognosis of the Scrum Team for product increments needed for the next Sprint.
      The activities are estimated in working hours.
      A Sprint Backlog will be produced in the Sprint Planning Meeting at the beginning of every Sprint.

      Product Increment
      The sum of all Product Backlog items which, during the actual and last Sprint, have been completed.

  • Large Projects

    Open or Close
    Large projects in Scrum consist of more than one Team. Generally, each Team has its own PO and SM. We differentiate between Distributed and Large Scrum Projects.

    Distributed Scrum Projects can exist in different buildings, areas, time zones and belong to various organisations.
    Distributed and Large Scrum Projects need increased communication and integration.

    Since every team has its own PO, it makes sense to appoint a     Chief Product Owner and further Stakeholders/Specialists.
    The Chief Product Owner who has more than 5 POs should not lead his own Team.
    The Teams can be divided into     Component and Feature Teams.
    A Component Team has the structure of the software architecture.
    Feature Teams are organized by Requirements.
    Basically, use only one Product Backlog.

    In the     Multi-Team Planning there should be a Release Plan provided, which applies to all Teams. Most Sprints are synchronized, however, asynchronous Sprints are also possible.

    Scrum of Scrums
    This means nothing more than a Daily Scrum, which will be conducted for the entire project. Each Team has a member, who participates in the meeting.

    Meta Scrum
    A Meta Scrum is the Scrum of Scrums and will be conducted for all projects.
Scrum offers many advantages in software development.
We analyze an intended plan for optimal realization and advise and support/coach the use of Scrum Management Framework.

We support both large and small Scrum projects, adapting a suitable migration from a classical organization to an agile organization.
U
© 2018 Holger Mayer Consulting HMC2