Scrum is a well-known and proven framework and methodology for managing product development. For purposes of project tracking and in the most basic terms, it consists of:

  • Managing a prioritized product backlog of unfinished product features, unresolved defects, and other items whose implementation or resolution will improve the product.
  • Increments of time called sprints, when a specific group of product backlog items are worked on and delivered.
  • A team of individuals who are responsible for delivering a new version of the product at the end of each sprint. This team includes a product owner who represents the customer's best interest and manages the product backlog. Secondly, the scrum master facilitates day-to-day work on the sprint. Finally, the development team is responsible for the doing the actual work.

There are other elements to Scrum, but the above are most relevant to project tracking and scrum's workflow.

Scrum Versus Rule-based Discretionary Tracking

First, it should be noted that Resultra is not specifically designed around Scrum, but is flexible enough to support Scrum-based tracking. Resultra's focus on rule-based discretionary tracking does not make it partial to one particular project management framework or another. It is only the implementation of a tracker in Resultra which corresponds with a particular framework or set of rules. In this regard, there is not really an "apples to apples" comparison between Resultra's rule-based discretionary tracking and Scrum.

Resultra is based upon the concept of "rule-based discretionary tracking" (RBD tracking), whose origins are actually from a type of stock market trading which is systematic and based upon rules, but also leaves room for discretionary overrides and extensions to the rules. Scrum originates from a Harvard Business Review article which proposed a new approach to product development. The term "Scrum" originates from a huddle in the sport of ruby. So, Scrum and Resultra both have at least one thing in common: they both partially trace their origins to something outside the field of product development.

Even though Resultra and Scrum have different origins, Resultra's focus on rule-based discretionary tracking is compatible with Scrum in a number of ways. For example:

  • Scrum requires prioritization of the product backlog. To help prioritize the backlog, Resultra can support anything from a single priority field to a multipart checklist.
  • Resultra also tracks every change to tracking information with its "tick by tick" tracking; this information can be summarized to monitor a Scrum sprint's progress.
  • Scrum places importance on clearly defining what it means for a sprint's task to "done"; accordingly, Resultra's trackers can be customized to support different definitions of task completion, such as a single checkbox or a multipart checklist.

A rule-based discretionary approach to project tracking supports and emphasizes using discretion to extend and override a product development framework (base system and set of rules); this may be necessary for current business conditions, the type of product being developed, the organization's risk tolerance, a competitive edge, etc. Although many parts of Scrum are very flexible, according to Scrum's definitive guide, some parts of Scrum shouldn't be changed:

Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum

Personally, I've never worked on or managed a project which didn't have variations, exclusions and other changes versus an underlying product development framework. For example, on some projects it doesn't make sense to use Scrum sprint's time-boxed implementation of one month or less. At the expense of saying these types of projects are "not Scrum", it is arguably more important to trust the discretion and experience of team members to flexibly adapt the product development as needed. Nonetheless, using a well-known and proven framework and methodology as a base or starting point is undoubtedly a good practice.

A Basic Scrum Implementation with Resultra

Resultra implements support for Scrum tracking with a custom tracker. This tracker is also provided as a factory template which can be used on your own projects. Basically, this tracker is setup as follows:

  • There is a form to create new items and add them to the product backlog.
  • The product backlog is implemented as an item list. In this list, the item's priority and estimate are shown in a table view.
  • A 2nd item list shows the unfinished items assigned to the current sprint. By default, this list is sorted to place the highest priority items at the top.
  • A 3rd item list shows the items which have been completed.
  • Each item has a "Target Sprint" field which determines which sprint the item each item assigned to. From the product backlog list, there is an alternate table view to prioritize and target individual items.
  • Each item also has a "Remaining Work Estimate" field. An item is considered finished when the remaining work transitions to zero hours. In other words, work is considered "done" when the remaining work "spins down to zero". Accordingly, when this field is shown in forms and table views a spinner control is shown alongside the value.

Below is a screen capture of a sprint list, populated with some project data:

ResultraScrumTemplateSprintList

After an item has been targeted to a sprint, this list is where to day-to-day tracking is done. Notably, a team member can "spin down" the remaining work estimate as the work progresses. Comments with status updates can also be entered directly in this list. The item's priority is used to sort the list; however, this information is read-only in this particular list. Finally, a button at the right-hand side of the list opens up a form to view more detailed 'work in progress' (WIP) tracking information for the individual item.

The lists for the product backlog and completed items look similar to the sprint list, but have different columns.

Going beyond this basic implementation, Resultra's trackers can be extended and customized for different types of projects or more sophisticated tracking.

Using Assessments to Prioritize the Product Backlog

The most basic implementation of a priority for backlog items is a single "Priority" field, typically shown with a rating control in a form. The basic tracker described above uses this approach.

However, one of Resultra's key features is support for assessments and combined/weighted priorities. Going beyond a singular representation of priority, a scrum-based tracker can be customized with an "overall priority" that is comprised of individual assessments like the following:

  • Is this feature expected to increase revenue?
  • Will fixing the defect decrease the product's support overhead?
  • Was the feature requested by a large customer?

To implement an overall priority, a calculated field would be used to sum up the weighted values from each of the individual assessments. As an example, Resultra's tracking template for content marketing also uses assessments for an overall prioritization.

What's Your Definition of "Done"?

Scrum places importance on a clear definition of "done". The definitive Scrum guide explains it this way:

When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means.

A basic implementation of Scrum considers an individual task done when there is no more remaining work. The overall sprint is done when there is no more remaining work on any task.

However, Resultra's trackers can be extended and customized to support other definitions of "done". This gives Scrum teams flexibility and room to grow, depending on what type of product is being developed, how formal or informal the project is, progressively more stringent quality control, etc.

Consistent with Scrum's emphasis on clearly defining "done", Resultra is flexible enough to support various definitions of "done", such as:

  • The developer's estimate of remaining work transitions to zero.
  • A single checkbox indicating the task is done.
  • A well-defined, product specific checklist, whose completion indicates the task is done.
  • The task is marked with a completion date.
  • A combination of the above. For example, a task could be considered done if both the remaining work is set to zero and a quality control checklist is completed.

As an example, below is what a multipart checklist for task completion could look like in Resultra:

ExampleFormulaChecklist

Monitoring Progress

During a sprint, Scrum mainly focuses on monitoring the total work, work performed and work remaining in a sprint. Resultra supports dashboards which summarize this information.

Specifically, Resultra implements "tick by tick" tracking of project information, meaning every single change to project information is saved. When a scrum developer updates the remaining work for a sprint's task, the dashboard results will update to reflect this change. Resultra dashboards can report summary results over fixed time increments, so the trends of "burn down" of work remaining and "burn up" work performed vs. total work can be monitored.

Supporting Scrum's Roles

At the time of this writing, Resultra's initial release is a desktop program for single-user or personal project management. Therefore, the basic Scrum implementation described above doesn't delve into the different Scrum roles, such as product owner and scrum master. In other words, for single-user or personal project management, all of Scrum's roles are fullfilled by a single person, so implementing role support is not needed.

The above being said, Resultra is built from the ground up to support teams with different roles and who collaboratively use Resultra for project tracking. Since Resultra's roadmap includes configurations which support multiple users, it is useful to discuss how Resultra's roles can be used with a scrum-based tracker.

In Resultra, roles determine who can create new items (tasks), view different lists, and view different dashboards. In a highly cooperative Scrum team, there may not be a need to restrict certain team members from viewing or editing different parts of the tracker. However, roles can also be useful to show and hide information which may or may not be of interest to different team members. Below are some examples of a tracker being customized according to a Scrum team's preferences:

  • Everyone on the team can view the main product backlog, implemented as an item list in Resultra. However, since the product manager is responsible for prioritizing the backlog, a second "Backlog Prioritization" list may only be visible to the product manager.
  • Besides the main list of sprint items, each developer can have a "My Sprint Items" list of the current sprint's items which are individually assigned to that team member.

Summary

Scrum is a well-defined and proven framework for developing and sustaining products. Resultra is also based upon a well-defined, "rule-based discretionary" methodology, but is not specific to any one framework (set of rules, artifacts, etc.).

The Resultra software application itself focuses on the project tracking aspects of a rule-based discretionary methodology. Resultra comes with a tracking template which is based upon Scrum and supports management and tracking of Scrum product backlogs and sprints.

Resultra and Scrum are definitely an interesting combination. Resultra supports important parts of Scrum, such as prioritizing the product backlog, clearly defining what it means for a task to be "done", and monitoring sprints' progress. However, going beyond basic Scrum support, and consistent with the rule-based discretionary methodology, Resultra project tracking can also be flexibly customized and extended to further support the unique and evolving needs of a specific product's development.