This Template Example is a copy of the ScrumBLer example
This example is meant to serve both as a template and as an example for the type of project description we are looking for.
SCORE Project: ScrumBLer
Title: Scrum Backlog Manager
For this project your team will create a team tool to manage a Scrum project backlog. Your tool will be used by a Scrum development team to create, manipulate, and manage their project backlog.
Project Description
Scrum is an agile software development methodology that centers around the creation of a product backlog of tasks (user stories, internal project tasks, etc.) that need done. At the beginning of each sprint (iteration) a selection of a set of those tasks is performed, which forms the sprint backlog, and this is what is worked on during that sprint. For learning about Scrum, the resources at Agile Alliance are always good, and the Wikipedia page on Scrum has some good information (but be careful, do not assume Wikipedia is authoritative or always accurate); many other resources for understanding Scrum are out there.
In Scrum, maintaining the backlog is the key process management task. This project involves creating a software tool for doing this. This tool should provide all the capability a team needs to create, manage, view, use, and analyze their product backlog and the sprint backlogs. Sprint backlogs are created by selecting tasks from the product backlog, are fixed once the sprint starts, and typically have unfinished tasks at the end of the sprint that then go back to the product backlog (whether they actually "leave" the product backlog in the first place is left as a design decision).
Tasks probably have some structured definition, but they must at least have a priority and an effort estimate associated with them. Effort estimates can be constrainted according to agile estimating principles (e.g., requiring Fibonacci numbers) but do not have to be.
Your tool must also be able to take the accumulated process data and generate analyses of how the development project that is using your tool is proceeding. Typical analyses are project burndown charts and measures of project velocity, but you can be creative and come up with some of your own. Even data reductions to something displayable in a lava lamp can be useful! Also views that would be appropriate for large wall display might be nice! (see here and here)
Project Scope
Your project needs to handle all of the basic capabilities described above, including managing the project backlog and creating and managing the individual sprint backlogs. Items that are on the product backlog probably come from user stories or other types of requirements, but your project does not need to be concerned with managing requirements. (It might be worthwhile to have some ability, such as a CSV file upload, that could add items to the product backlog automatically rather than requiring manual entry; this could allow integration with other tools.)
Your project may be a desktop application or may be a web application. A desktop application might use simple local file storage with its file(s) kept as part of the project repository, but if so care should be taken regarding the issue of repository merges from multiple updates.
Your project does not need to be able to manage multiple development teams in one installation, or at least multiple projects do not need to have any interacting information.
Your project should be able to export data so that other tools might be able to use the data it has; this can include CSV export of backlogs, export of metrics calculated from process history, etc.
Process Requirements
Your team must "eat your own dog food" -- in other words, you must use your own project tool as soon as it is at its first usable state. Your team must show documentation that demonstrates usage of your tool for at least two sprints.
Environmental Constraints
None.
Level of Sponsor Involvement
The sponsor of this project will accept questions about the project topic during the periods 15 Jan 2015 to 10 Feb 2015; 1 Jun 2015 to 15 Jun 2015; and 15 Aug 2015 to 15 Sep 2015. At least by the end of each of these periods (but possibly sooner), selected questions deemed important by the sponsor will be gathered and answered in a FAQ at the bottom of this page. Questions not appearing on the FAQ will not be answered, and teams will have to make their own assumptions for those questions.
Sponsor contact: joncook (at) nmsu (dot) edu
Project Restrictions
Projects are not restricted from using external software, and it is recognized that effort is required to effectively use external packages; however, project evaluation will take into consideration how much of the project was created as original software by the team.
Project FAQ
Answers to selected questions will appear here.