16 June 2021

The Scrum Framework (1)

Scrum framework :

  • Scrum is a framework
  • Scrum is defined as a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
  • Scrum is initially developed for managing and developing products.
  • Scrum is a framework to support teams in complex product development, framework within which you can employ various process and techniques.

The Scrum Framework :

  • The Scrum Framework consists of Scrum Teams and their associated events, artifacts, and roles as defined in the Scrum Guide.
  • According to the Scrum Guide, mandatory rules and principles of Scrum are Scrum Roles, Scrum Events, Sprint Goal, Product Backlog, Sprint Backlog, Increment, Definition of Done, and Monitoring progress in Sprint and Project levels. Other things are practices that can be employed in the Scrum framework and are up to the team and project and are not mandatory.
  • In The 2020 Scrum Guide Roles are remplaced by Accountabilities.

Scrum Guide :

  • The definition consisting of scrum roles, events, artifacts, and the rules that bind them together.
  • The definition of Scrum, written and provided by Ken Schwaber and Jeff Sutherland, co-creators of Scrum.
  • Scrum Guide here.

The Scrum roles :

  • Product Owner
  • Development Team (Developers)
  • Scrum Master

The Scrum artifacts :

  • Artifacts represent work or value to provide transparency and opportunities for inspection and adaption.
  • Artifacts are defined by Scrum and designed to maximize transparency of key information so that everybody has the same understanding.
  • Product Backlog
  • Sprint backlog
  • Increment

The Scrum events :

  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Sprint Retrospective
  • The Sprint is the container for all events

Scrum Rules :

  • According to the Scrum Guide, mandatory rules and principles of Scrum are Scrum Roles, Scrum Events, Sprint Goal, Product Backlog, Sprint Backlog, Increment, Definition of Done, and Monitoring progress in Sprint and Project levels. Other things are practices that could employ in the Scrum framework and are up to the team and project and are not mandatory.

Scrum characteristics :

  • Scrum is lightweight
  • Scrum is simple to Understand
  • but Scrum is difficult to master.

Scrum use :

  • Scrum is used for :
    1. Research and Identify viable market.
    2. Develop/Release products/enhancements.
    3. Develop & sustain Cloud/operational environments
    4. Sustain/Renew Products

Scrum Values :

  • Scrum Values are
    1. Commitment
    2. Courage
    3. Focus
    4. Openness
    5. Respect

Scrum and Empiricism :

  • Knowledge comes from experience, decisions are based on what is known.
  • The process control type in which only the past is accepted as certain and in which decisions are based on observation, experience, and experimentation.
  • Empirical Process Control : Iterative, incremental approach used by scrum to optimize predictability and control risk.
  • 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. Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.
  • Three Pillars of Empirical Process Control
    1. Transparency
    2. Inspection
    3. Adaption

Transparency :

  • Transparency means significant aspects of the process must be defined by a common standard and visible to those responsible for the outcome.
  • Transparency can be created by having a common language referring to the process that is shared by the participants.
  • Transparency requires that those performing the work and those inspecting it share a common definition of “done.”
  • Scrum is based on agile so collaboration is the most important thing that can help the Team to increase transparency. Also, effective collaboration needs a common language. In addition, having a Definition of Done is another important thing that can increase transparency.
  • Transparency increases the value and control risk of the decisions made to optimize value in Scrum.
  • Transparency means the process is understandable by all stakeholders.

Inspection :

  • Inspection should be done with artifacts/progress frequently enough to detect undesirable variances, but not so frequently that it becomes an obstruction.
  • Inspection is most beneficial when done at the point of work by skilled inspectors.
  • Inspection should be done with artifacts/progress frequently enough to detect undesirable variances, but not so frequently that it becomes an obstruction.

Adaptation :

  • When an inspector determines that one or more aspects of the process deviate outside the acceptable limits, the product becomes unacceptable.This process/material must then be adjusted.
  • When should a process adjustment occur? After it is deemed necessary as soon as possible in order to avoid deviation.

Time-boxing :

  • A time-box is a timeframe with a maximum duration. It means you can work in a time-box and if you achieve its goal, you can terminate it earlier. However, if you do not achieve its goal at the end of the timeframe, you cannot extend it.
  • A time-boxed Sprint means that this event has a maximum duration that is fixed and cannot be shortened or lengthened once the Sprint has begun.
  • Except for the Sprint, all other Scrum events can be terminated before their time-box if the Team has achieved the event’s goal.

Progress :

  • The Product Owner is responsible to monitor the progress of the project toward a business goal at least for every Sprint Review and the Development Team is responsible to monitor the progress of the work to the Sprint Goal at least for every Daily Scrum.
  • Monitoring the progress is mandatory, but the way you made it is your choice.
  • These practices are protective practices used to forecast progress.
    1. Burn- Up Chart
    2. Burn-Down Chart
    3. Cumulative Flows

Burn-down Chart :

  • A chart showing the evolution of remaining effort against time. This is optional and makes progress more transparent (y-axis shows total remaining work and x-axis shows time).
  • Burn-down Chart is not mandatory in the Scrum framework.
  • Burn-down chart Y-axis usually shows total remaining work and X-axis shows a type of time i.e. Sprint days in Sprint burn-down chart and Sprint numbers in Project burn-down chart.
  • Sprint burn-down chart indicates the remaining work of each day during the Sprint. Its Y-axis shows total remaining work and X-axis shows Sprint days. If you draw a trend line from the Sprint beginning remaining work to the last day of the Sprint on the X-axis, you will have the plan trend line and you can compare actual and plan progress daily in order to resolve deviation as soon as possible if needed. Increasing to the remaining work during the Sprint is natural because new tasks could emerge when the Development Team learns more about the work.
  • Burn-down chart shows the evolution of remaining effort against time. A burn down chart is a graphical representation of work left to do versus time. That is, it is a run chart of outstanding work (X-axison the Burn-down chart shows he project/iteration timeline, Y-axison the Burn-down chart the work that needs to be completed for the project, the Lines on the Graph show the Actual Task Remaining Vs the Ideal Task Remaining).

Burn-up Chart :

  • Burn-up Chart is a chart showing the evolution of remaining effort against time. Optional, increases transparency.
  • Burn-up Chart is not mandatory but optional in the Scrum framework.

Forecast of functionality :

  • Forecast of functionality is the selection of items form the Product Backlog a Development Team deems feasible for implementation in a Sprint.

Scrum Board :

  • Scrum Board is a physical board to visualize info for and by the Scrum Team, often used to manage Sprint Backlog.
  • Scrum boards are optional within scrum and make information visible and increase transparency.

Quality :

  • All the Scrum Team members are responsible for the product’s quality. In the Scrum as an adaptive approach, quality and test should be considered from the beginning of the development. It leads to more transparency in the Increments, ensures to have releasable Increments, decreases the risk of reworks and as it helps to produce reliable Increments, customer feedback will be around business expectations not about bugs or wrong implementation so it improves customer feedback’s level.
  • All members of the Development Team are developers and there is no title such as programmer, tester, QA member,etc. These are skills that each member might have some of them and accountability of the product quality belongs to the whole Development Team, not a special member.

Requirements :

  • In order to prevent creating the wrong product or having reworks, it is valuable using some approach to make a better understanding of customer requirements. These approaches are Sketch, Wireframe, Mockup, and Prototype. In addition, all of them occur before implementing any code.

Non Functional Requirements :

  • Non‐functional requirements or cross‐cutting concerns are the features of the design that may apply across all layers and are related to the quality requirements. There are many non‐functional requirements as following: Security, Reliability, Performance, Availability, Globalization, Scalability, Maintainability, Robustness, etc. They can be managed by adding them to the Product Backlog or adding them to the Definition of Done.
  • Non-functional requirements describe qualities of the system being developed. E.g. the system should be secure, extensible and have acceptable performance. The way to meet such requirements is:
    1) Have them as a part of the Definition of Done and check the applicable Increment against these criteria.
    2) Add them as the Acceptance Criteria to the applicable Product Backlog Item.
    3) Include them as Product Backlog item itself.

Specification by Example :

  • Specification by Example calls for using realistic examples from past experience instead of untested or abstract statements in the description of the desired functional behavior.
  • Specification by example (SBE) is a collaborative approach made to define requirements and business-oriented functional tests for software products using realistic examples instead of abstract statements.

Velocity :

  • Velocity is the indication of the average amount of Product Backlog turned into an Increment of the Product during a Sprint by the Scrum Team.
  • Development Team tracks the velocity for use within the Scrum Team.

More informations for the Scrum PSD certification here.

Leave a Reply

Your email address will not be published. Required fields are marked *