Hitachi Vantara Pentaho Community Wiki
Child pages
  • 14. Sprint Template
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 21 Next »

This template is just that - a guideline - not a mandate to slavishly follow a methodology that doesn't fit. While the agile methodology exists for a reason, so does the sprint, and there are bound to be occasional mismatches that warrant side-stepping certain aspects of the process. This template will help you keep your sprint intact, but in a sensible way that actually fits the team. It discusses ways to accommodate different needs of the project so as to communicate where you can and can't cut corners.


 If you haven't already, you should review the Sprint FAQ page to better understand what "Open Scrum" entails.

Kick Off Meeting

 Schedule and conduct a Sprint kickoff meeting - invite the right stakeholders.

Requirement - Official announcement via email of a project's start and identification of the scrummaster and the Backlog list of planned features.

Status - Keep everything visible

Communication with and among sprint team members and stakeholders, internal and external, must be constant. The project team needs relevant information, in a timely manner, from each of its members to complete and improve the project, and to understand the needs and expectations of project outcomes. Since change is constant in an agile project, constant communication is the only means of maintaining the connections among all the participants. "Going dark" for any significant amount of time is simply not feasible. Project communication management involves planning, information distribution, performance reporting, and formal project close-out. These are the elements a Sprint team must agree to and be facilitated by the Scrum Master.

A scrum (or Sprint) is controlled by means of frequent (daily) inspection of the progress followed by necessary adoptions. Most times this is done face to face. In any Sprint people are going to want to know the progress, the tone and the attitude of the team.

A weekly demo works to allow outside but interested members to see and hear what's the current status.

Currently reviewing a project status application - Mingle - JM 

What you see is what you get! 

Cards (or sticky's)-on-the-wall is a valuable project planning technique. Cards identifying individual tasks are affixed to a wall. The tasks are linked with string to represent precedence. This collection of cards and string represents a network of tasks: the project plan. An implementation of this might be to use colors to represent activities in the project. A color might be selected to represent features: features that were designed, developed, tested and in production one color; features that were designed, built, tested but not yet put in production (but ready to go) another color. The team in this scenario is able to visualize where they stand with each feature set. Visual control is a valuable technique for all projects, since it ensures that every member of the team views the project the same way.

Sprint Feature Backlog

During the Sprint, that Backlog is fixed and can only be changed as a result of the work being performed in that Sprint. The Backlog which is basically the current requirements (not tasks) list will be publicly available on the project website.

The Backlog outside the current sprint/s is always changing, evolving and being re-prioritized. As contributions are accepted from community the Sprint backlog needs to be updated. New requirements need to be prioritized and grouped in some logical order.

In addition to the typical Scrum information the 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.To be maintained in JIRA - re-work underway for improvements.


The scope of the Scrum Team will include the community as they will help provide peer review of the design, implementation, testing, documentation, usability feedback etc. If needed, (and possible) the designation 'Core Scrum Team' and 'Extended Scrum Team' may be used.

Identify who's on the team and what is their primary function? Ensure the team understands the Backlog and what are the primary features that are to be coded. Note any vacations or upcoming holiday's that might be a factor during the Sprint.

Also, establish rules of engagement for the team ie: Every developer will ensure that code is unit tested before being checking in. ie: see Daily Scrum Meetings.

Daily Scrum Meetings

The Core Scrum Team needs 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 but work best face to face.

Establish the time and place for the daily Scrum meeting and if a dial in is required. The Scrum team is responsible for ensuring members are present. The ScrumMaster simply ensures the conversation stays focused and tracks and manages the blockers.

How To Contribute?

Add Community Links here - DM

Burn Down Charts

Use a chart that shows progress throughout a Sprint and ensure it is transparent to the extended team.

Development Process

  • No labels