Hitachi Vantara Pentaho Community Wiki
Child pages
  • 05. Scrum Methodology

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin
Wiki Markup

To summarize the Scrum methodology:

  • The wish list of features for the software are gathered together into a Product Backlog. This is owned by a Product Owner.
  • The features on the Product Backlog are implemented in a series of Sprints. These Sprints are performed by a Scrum Team with the help of a Scrum Master.
  • At the start of each Sprint the stake-holders, Product Owner, and Scrum Team agree on a subset of the Product Backlog to implement during the Sprint.
  • The features developed during the Sprint should be complete at the end of the Sprint. That is to say they should have been prototyped, implemented, tested, and documented during the Sprint.
  • At the end of each Sprint the Scrum Team demonstrate the new features to the stake-holders and the cus-tomer can take software and inspect or trial it.
  • At the end of any Sprint the stake-holders can decide that there is enough functionality to release the soft-ware.

It is apparent from this list that the Scrum methodology could easily be used to create the milestone releases that are common in open source projects.

Scrum is often diagrammed in a way similar to this:

SP = Sprint Planning SR = Sprint Retrospective

This diagram shows what happens to the features as they go through the process. This diagram gets some basic ideas across but it over-simplifies several things.

  • It does not convey the fact that the Product Backlog changes over time, some items are completed during Sprints and other features are added as new ideas come to light. This flexibility in the feature-set is a critical difference between Scrum and defined methodologies such as Waterfall.
  • It does not convey the work of the Product Owner to update the Product Backlog
  • It does not convey the fact that the Sprint Planning session for the next Sprint happens after the Sprint Retrospective.
  • It does not include any bug fixing, acceptance testing, or any feedback from the users or consumers of the software that occurs after the end of the Sprint. It does not convey that the features might be 'complete' in that they have documentation and have undergone unit testing and integration testing, but that they have not undergone acceptance testing from the users / customer / consumer.

If the points above are resolved the diagram looks like this:
PO = Product Owner SP x = Sprint Planning SR x = Sprint Retrospective F&A x = Fix & Accept
As you can see the diagram is more complicated than the previous one.

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 works on the Product Backlog as Sprints are under way.
  • The Sprint Planning for the next Sprint happens after each Sprint Retrospective.
  • Features are complete after a Sprint but not yet accepted (done).
  • There is a phase after the Sprint where bug fixing and acceptance testing are done. This happens in parallel with subsequent Sprints. The Fix & Accept phase can be scheduled to occurs and complete during the next Sprint.