Scrum tool

This is a tool to plan and track a scrum project. This version is an almost literal translation of a spreadsheet that was in use for the same purpose. It partially supports a scrum team to plan and track a scrum project. It does not support the typical artifacts described in scrum literature exactly, but enables the execution of a scrum project with tolerable deviation from the documented process.

Running

The tool itself is a single HTML file, with embedded Javascript and CSS code, inluded from their published CDNs. As such, it works when directly opened in a browser, but this has not been extensively tested, especially accross operating systems and browsers. During development, it was tested using Node JS as the web server, and should work on practically any other server as well.

User Interface

Opening the HTML file in the browser displays a row of buttons on top, a row of tabs, and the view of the project below. The starting screen looks like this:

The topmost row of buttons allow import and export of projects. Projects are stored as JSON files, which can be loaded later for further editing.

The Load Project button allows a project to be loaded from a local JSON project file. The idea is to continue work on previously saved project files. Save Project saves the current data into a project file. The filename is generated from the project name and the timestamp by default, and can be changed. It will be saved to the directory your browser uses for dowload. This may mean that the saved file is renamed to prevent overwriting an existing file, or similar behaviour specific to your brouser, including the location of the downloaded file. Chages are not saved by default - work needs to be explicity saved periodically. Clear Project removes the current project, and starts with an empty project. This is the same effect as reloading the page.

There is a row of tabs below these buttons, that are used to edit or view the project.

The Planning tab is used to list all the requirents bein considered for inclusion into the project. Requirements here are listed and estimated, but not yet included in the project for implementation. This form is inteded for use in the early phase of the project before finalizing content for tracking.

The Bandwith tab contains some general settings for the project on the whole, including:

• Project Name, which is used to generate the default name of save file.
• Start Date of the project, which is the Monday of the week of the first milestone.
• Team, which is a list of the people in the project, and their roles - lead, developer or QA
• Milestones, which a list of perdiods starting from the start date of the project, and running continuously in sequence, with no gaps.
• Blackout Weeks, which are a list of weeks in which all or many people in the project are expected to be unavailable, leading to little or no burndown of project work.

The Tracking tab lists all the requiremnts in the project, and their current status against the schedule.

The Graphs tab shows views of execuiton using graphs.

• Milestone, which shows the burndown in each milestone, and the work assigned to each developer
• Release, which shows the burndown across the whole release
• Feature, which shows the remiaining work per feature and per developer

The Settings tab allows the tab order to be set for convenience when editing in a specific phase of the project.

Workflow

The tool does not impose a workflow, but there is a loose coupling between tabs that would lead to a different user extperience based on how the tool is used. There is a workflow described here, which is the most typical way to use the tool, but actual usage can deviate to accomodate execution convenience. The typical workflow is expected to be a planning phase when the product owner and the team collaborate on walking through the requirements to estimate them, prior to planning the milestones. To draw up the schedule, the team availabily is tabulated accross a series of milestones. Then in the tracking phase, the burndown is periodically updated. The tools usage will be desribed assuming that workflow for simplicity, and it is possible to deviate in practice to accomodate real life. While this is the broad workflow that the tool supports, it is possible to go back and forth.

To start with, the product owner would have a set of features, from which the next version of the product is to be planned. The team would need to discuss and estimate these features to come out with the plan for the release. The product owner lists all candidate features in the planning tab, and works with the scrum team to come up with estimates that would lead to the project schedule. This is ducumented is the planning tab in the tool. There is a table of requirements on the Planning tab, that looks like this:

The colomns in this table are:

• ID, a unique identifier for the requirement from a tracking system, such as JIRA, as an external key to that system
• Description, a description that cn be used by the team to understand the feature for estimation, planning and development
• Importance, the relative importance of the feature, to make decisions about inclusion or exclusion, if needed
• Story pts, the size of the feature, in whatever unit the team uses, such as story points, t-shirt sizes, stone sizes, ...
• Days, the number of days to be considered for planning, which is a refinement of whatever was entered in the Story points column

When the team has all the features estimated, or enough estimated that can be done in a release, the next thing is to work out the schedule. This is a function of the number of developers, the effort available from each developer for the project, the number of milestones planned, and any significant long holidays during the duration of the project. These are set up on the Bandwidth tab. This tab has the following panels:

• Project Name, which is used to default the name of the save file, apart from letting the viewers know what they are looking at.
• Start Date, which sets up the first date of the first milestone of the project. The dates of the milestones are calculate based on the start date and lengths of each milestone.

• Team, a list of developers, QA and tech lead of the project. The computation of capacity for the lead defaults to 40% and the developer to 80% when the capacity for milestones are calculated in the Milestones panel.

• Milestones, the project schedule is broken up into milestones, each a cerain number of weeks long, with a default assumption of 5 working days a week. There are ways to work arout this mentioned in the FAQ section below. The capacity of each developer can be diferent in each milestone, as can be the amont of planned vacation.

• Blackout weeks, are weeks in which vacations such as Diwali, Thanksgiving or anything similar is going to see all or a major part of the team out of office, resulting in little or no burndown for the project.

Once the requirements are estimated and the capacity information is entered, the schedule can be detailed in the Tracking tab. All the features to be included for development are listed here, with additional information about schedule. Each row is the plan and execution data around a single requirement.

• ID, the ID of the requirement in the requirement tracking system, such as a JIRA number
• Description, a description of the feature
• Team, the developer and QA assigned to this task
• Status, what is the status of the task so far, which could be "Not Started" before a developer takes it up, from where it could move to "In progress" when taken up for development. If development is blocked for any reason, it would move to "Impeded", until the issue is resolved, while the QA and developer roll on to the next feature. If the issue cannot be resolved, the task could become "Obsolete", which would be a way to soft-delete a feature, which retains the other information to be easily brought back, if the issue is resolved. Finally "Completed" indicates that the development and QA are done for the feature.
• Notes, allow free form notes to be taken to capture inputs from the QA and developer on progress. As a convention, the format ': ' is a useful way to use this section.
• MS indicates the milestone in which development will be done for this feature
• Est. the estimate for the feature at the start of development. As a practise, this should not be changed after planning. It is better to burn up the remaining effort (i.e. increase the remining effort), than to change the estimate. This preserves what happened for a project retrospective.
• Burndown, which registers the remaining effort each week for the feature, until the QA is done.

FAQ

• How can I start with a planning milestoe, which is used for design, POCs and other activities not directly contributing to burndown?

You can make the capacity of the milestone reflect this. Reduce the capacity of the team members anywhere down to 0% to refleact that their activity was used for requirements discussions, design, prototyping, demos, trainng or whatever, but not amounting to code that went into the product. It is possible to allocate hours and track against some activities, but it they do not go into building the product, analysis on time it took to purely build the product becomes hard to extrct and analyse.

• How can I create gaps between Milestones?

One way would be to add blackout weeks at the beginning or end of a milestone. Another would be to have a milestone with no work assigned inbetween.

• How can I use a 6 day week?

The percentage utilization is based on a 5 day week, and raising this by 20% per day gives more capacity. The default of this to 80% in the tool is meant to reflect that while 4 days a week goes towards developing features in the releae, one day is reserved for other non feature building activities, such as interviews, training, defect fixes in previous versions of the software, reviews of other peoples work, meetings, and so on. Based on how much non-project effort is anticipated this could be dialed up or down. The default for a lead is set to 40% assuming that the lead will spend time reviewing other peoples code, triaging issues, tracking details, etc, and wont have all time available to sppend on development. These numbers are defaults that can be altered to match project realities.

• How can I assign an exceptional developer more work?

By increasing the developer capacity to reflects their relative productivity - like 150% or 200%. Wach out for buy in and burn out when doing such things.

• How can I start on a day other than a Monday, or end on a day other than a Friday?

Pad holidays into the schedule. The default settings have 2 holidays per developer into each default 4 week milestone. The number of holidays can be bumpled up to reflect starting later than a Monday. However, the week boundaries do not overlap, so finishing a milestone in the middle of a week, and starting the next one in the same week would not work.

• How can I accomodate different amount of productivity for newcomers, senior vs junior developers, part timers, poor performers...?

You can change their capacity to reflect how much they can burn down. The reason is not captured. Someone could be at 50% capacity because they were still ramping up on the technology, or were new to the product, or was just fresh out of college, or had health issues, or anything else. Setting the percentage to reflect the expected contribution for whatever reason covers all scenarios.

• How can I enter data for features that will take more than a milestone to develop?

The feature can be split into rows refecting the testable chunks, or activities that will be built in each milestone. Another way would be to transfer the development capacity to the next milestone by making it 0 in the current one. This is harder to track than the first method. The spirit of scrum being testable chunks every week, the first approach is preferable.

• How can I decide that the QA is done, and the feature is complete?

Create and use your own done criteria. One I used was that test cases needed to be written up front, divided into acceptance and alpha tests. The acceptance tests had to pass for us to claim the feature was supported. The alpha tests walked through the major use cases of the feature. 100% of the acceptance and 90% of the alpha test cases had to pass for the feature to be considered built. If not, the feature could be moved to the next milestone or even droped. The milestone could be extended till the test passed, but the scrum methodology frowns on that.