Hitachi Vantara Pentaho Community Wiki
Child pages
  • 07. Open Scrum
Skip to end of metadata
Go to start of metadata

The Scrum methodology only has 5 aspects (above) that need modification in order to create a better fit for use in open source projects. This modified methodology 'Open Scrum' can be described by defining where it differs from Scrum.

SCRUM FEATURE

OPEN SCRUM FEATURE

Product Backlog

Feature Backlog

The full wish-list of features (and their stories) for the product.

Called 'Feature Backlog' instead. This should be publicly available on the project website. As contributions are accepted from community the Spring backlog needs to be updated. In addition to the typical Scrum information the Product Backlog needs to include a field that describes the extent to which an implemented feature has been hardened and accepted by the community. In order to get peer review and feedback on requirements and design the descriptions in the product back should include (or include references to) requirements and design documentation where possible.

Sprint Planning Session

Sprint Planning Session

A meeting during which feature from the Product Backlog are selected for completion during the upcom-ing Sprint.

The same. This should be publicly available on the project website. The extent to which the meeting is open to the Extended Team is up to the leadership of the project.

Sprint Retrospective

Sprint Retrospective

A meeting during which the features developed are demoed and lessons learned are discussed.

The same. This should be publicly available on the project website. This could take the form of a Blog with screen shots of the new features.

Product Owner

Product Owner

The person responsible for the Product Backlog.

In the case of most open source projects this role will be filled by an administrator, founder, or one of the core developers. In the case of commercial open source projects this role will be filled by a Product Manager.

Scrum Master

Scrum Master

The person responsible for tracking and coordinating daily updates.

In the case of most open source projects this role will be filled by an administrator, founder, or one of the core developers. In the case of commercial open source projects this role will be filled by a Product Manager.

Scrum Team

Scrum Team

The cross-functional team developing the software. This includes architects, developers, testers etc.

The scope of the Scrum Team needs to encompass the community as they will help provide peer review of the design, implementation, testing, documentation, usability feedback etc. If a distinction is needed (and possible) the designation 'Core Scrum Team' and 'Extended Scrum Team' can be used.

Stake-Holders

Stake-Holders

People that support the development process but who are not directly involved. The stake-holders are deter-mined before the first Sprint and typically do not change.

Stake-Holders include the founders, administrators and core developers of the project but also includes any community member who is actively participating. Because of this stake-holders needs to be solicited at the start of every Sprint.

Story

Story

A description of the use case for a feature

The same.

Sprint

Sprint

A time-bound (usually 4 weeks) effort to create finished features (tested and documented).

Longer (up to 12 weeks) Sprints are allowed for solo, or very small part-time core-developer teams

Burn Down Chart

Burn Down Chart

A chart that shows progress throughout a Sprint.

The same.

Sprint Backlog

Sprint Backlog

A list of the features that the Scrum Team is committing to completing in a Sprint.

The same. As contributions are accepted from commu-nity the Spring backlog needs to be updated.

Daily Scrum

Daily Scrum

A short, daily, meeting where the Scrum Team report progress, next steps, and obstacles that need to be overcome.

The Core Scrum Team need to synchronize frequently and the results of these interactions made public for the Extended Scrum Team. In the case of projects with full-time committers or commercial open source projects this should happen daily. In the case of solo or part-time core teams weekly or biweekly Scrums should be held. Scrum meetings can be held over instant messaging.

Feature Acceptance Review

Feature Acceptance Review

Not used.

This review, performed by the Product Owner, decides which features implemented in prior Sprints have been accepted by the project's community and have been sufficiently hardened enough to call them 'ready'. This review can be performed in conjunction with the Sprint Retrospective. This determination is not easy without the participation of the Extended Team.

As a diagram Open Scrum looks like this:


 

PO = Product Owner

SP x = Sprint Planning

SR x = Sprint Retrospective

F&A x = Fix & Accept

PR = Peer Review and Suggestions

As you can see the diagram is similar to, but not the same as the corresponding Scrum diagram.
The diagram shows that:

  • The Product Backlog changes over time. Features are completed and added each Sprint. Features are not completed in the order they were added to the backlog. After all the Sprints in a given release are finished there may still be features left in the backlog.
  • The Product Owner and community are both involved in the contents of the Feature Backlog. The contributions of the community to the Feature Backlog happen during all phases.
  • The Sprint Planning, Sprint, and Sprint Retrospective are XXX by the Core Scrum Team and the community participate as the Extended Scrum Team. The community can only participate in this if the Core Scrum Team enables them.
  • The Sprint Planning for the next Sprint happens after each Sprint Retrospective.
  • Features are complete after a Sprint but not yet accepted (done).
  • The Fix & Accept is longer and not time-bound. The community contributes significantly to this process. Since the community cannot be scheduled this phase needs to allow for an unknown completion date.
  • No labels

1 Comment

  1. Anonymous

    Hi

    I think you are confusing Sprint Retrospective with Sprint Review. It is the review session where the features are demoed while the retrospective revolves around the teamwork, process and practices.

    In other words, the sprint review is intended to be the Feature Acceptance Review you are looking for. In practice, this acceptance review is happening during the sprint already as features are completed.

    Regards
    Stefan (CSM & Agile Coach)