Agile@XOAP

At XOAP we use elements of SCRUM for all of our software and infrastructure development projects.

The official SCRUM guide can be found here. From this we try to follow the these aspects:

SCRUM Principles

Transparency

Have a common standard for all aspects that are shared amongst people. Eg. Definition of Done has to follow a standard defined by the team to ensure that those that work on a feature have the same understanding of “done” as those that inspect that feature. The team makes open and completed work transparent to each other and stakeholders (e.g. with an accessible, fully estimated backlog).

Inspection

The team inspects their work progress frequently to ensure that no unwanted discrepancy develops during the sprint. At the same time, the team ensures that inspection is not performed so frequently, that it gets in the way of the actual work to be finished in the sprint.

Adaption

If the inspection identified a discrepancy that requires adaption, it will be taken up by the team. There are 4 formal events that help to inspect and adapt, but it can happen at any time during the sprint outside of these events, too. (e.g. in code review).

  • Sprint Planning
  • Daily SCRUM
  • Sprint Review
  • Sprint Retrospective

Scrum Values

Following the below values and living them in our daily work, an environment of trust for each other will be build. That is the most difficult part and the essential foundation to work in an agile team setup.

Commitment

Everyone personally commits to achieving the goals of the team.

Courage

Team members have the courage to do the right thing and work on tough problems.

Focus

Everyone focuses on the work in the sprint and the goals of the team.

Openness

The team and its stakeholders are open about all work that has to be done and challenges that come up.

Respect

Team members respect each other to be capable and independent individuals who all work on the same goals.

SCRUM Roles

We use the same roles that are described in SCRUM.

  • Product Owner
  • Development Team
  • Scrum Master

In a SCRUM setup, a development team is at least 3, but should not be bigger than 9 people - according to a global research, the team size in which a team will work most efficiently is 5 people.

SCRUM Events

We are working in a sprint (time box) of 2 weeks for every iteration. We are using the official SCRUM events and are adjusting them slightly to our own needs.

SCRUM Artifacts

We are using the classical SCRUM artifacts, but have an additional dimension to store the product requirements.

  • Product requirements - In Microsoft OneNote
  • Product Backlog - In Azure DevOps

The Product Owner is responsible for the quality of the product backlog and has to ensure that the following criteria are met:

  • It should at any point in time transparently reflect the estimated work that has to be done
  • It should be ordered according to priority. Highest priority items are on the top
  • The items at the top are clearly defined and ready to be taken into the next sprint, the items more towards the bottom are roughly sketched out
  • Product backlog items that shall come to work next, have a reasonable size and can be completed in one sprint

Scrum Roles and their main tasks

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. The Product Owner is one person, not a committee.

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 Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint. Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Having more than nine members requires too much coordination.

Product Backlog

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful.

Product Backlog refinement(also known as Backlog Grooming) is the act of adding detail, estimates, and order to items in the Product Backlog. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team.Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones.

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.

Increment

The Increment(also known as shippable Product or Product Increment) is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.

Definition of “Done”

When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means.

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.

Sprint Planning

The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team. Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

Sprint Planning answers the following:

  • What can be delivered in the Increment resulting from the upcoming Sprint?
  • How will the work needed to deliver the Increment be achieved?

Daily Scrum

The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours.

Some Development Teams will use questions, some will be more discussion based. Here is an example of what might be used:

  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

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