Why SimpleScrumTools exists

Scrum as an optional template

The first four parts of this primer describe Scrum as the Scrum Guide defines it. A Scrum Team has a Product Goal and works toward it one Sprint at a time. Each Sprint has a Sprint Goal. Work counts only when it meets the Definition of Done. The events give the team a fixed place to inspect and adapt, and the Increment is the evidence of progress.

Now look at the tools that many teams use to run Scrum. Most popular project management tools are general-purpose work trackers. They track any kind of work for any kind of team, and that flexibility is their strength. Scrum usually arrives in them as one option among many. It is a project template, or a board type that you choose when you set up a project.

In my view, a template is not enough. A template gives you columns and a sprint container. It does not give you the things that make Scrum work. In a typical general-purpose tracker, those things end up in one of three places:

• Absent. The tool has no place for a Product Goal, so the goal lives in a slide deck or in someone’s head.
• Free text. The Sprint Goal is an optional text field. A sprint starts whether the field is empty or not, and nobody notices the gap until the review.
• Left to discipline. The Definition of Done is a wiki page. The event notes live in separate documents. Somebody rebuilds the Increment for the review with a filter or a spreadsheet.

Discipline works when the team is calm. It fails when the team is busy, which is exactly when Scrum’s structure matters most. A tool that treats Scrum as a template cannot help at that moment, because it does not know the rules. The team then runs a process that looks like Scrum but does not inspect or adapt.

What “Scrum-native” means

I built SimpleScrumTools on a different premise. Scrum is not a template in it. Scrum is the model. The Product Goal, the Sprint Goal, the Definition of Done, the events and the Increment are part of the product’s structure. They are not optional fields. Where the Scrum Guide states a rule, the product holds the rule, so the team does not have to remember it.

That choice also means the product does less than a general-purpose tracker. It does not try to fit every way of working. It fits one framework and tries to fit it well. The rest of this page lists what that means in practice. Each claim links to the help page that documents the behavior.

The goals are part of the structure

The Product Goal lives on the project. Each project in SimpleScrumTools has one Product Goal. It shows on the project screen, at the top of the Product Backlog and at the top of the Sprint Planning screen. A project without a Product Goal says so and prompts you to write one before the first sprint.

A sprint cannot start without a Sprint Goal. A new sprint starts in the Scheduled state. It cannot leave that state until it has a Scrum Team and a Sprint Goal. Once the plan is complete, the product refuses to clear the goal. During the sprint, the board shows the Sprint Goal at its top, every day.

Sprints keep a fixed cadence

Every sprint in SimpleScrumTools lasts one to four whole weeks. It starts on a Monday and ends on a Friday, in the team’s own timezone. The product picks each sprint’s start Monday after the team’s last sprint, so sprints follow each other in order. Two sprints of one team cannot overlap, and a team has at most one Active sprint at a time.

When you close a sprint, the product asks where each unfinished item goes: to the next sprint or back to the backlog. Done items stay with the sprint that finished them.

Done means Done

The Definition of Done gates the move to Done. Each project keeps its Definition of Done as a checklist. Each backlog item shows the checklist in its panel. An item cannot move to Done while any active line is unchecked. The same rule applies when somebody drags a card on the board and when somebody changes the status in the item panel. There is no second path around it.

The Increment is a query, not a document. Nobody maintains a list of what the sprint delivered. The Sprint Review screen computes the Increment each time it loads, from the sprint’s Done items. The items that did not reach Done appear beside it as Carried over. Two separate switches record whether the team demoed the Increment and whether it released it, because showing work and shipping it are different claims.

The events keep their own record

A Scrum Event is a session. In SimpleScrumTools, the Daily Scrum, the Sprint Review and the Retrospective each have their own screen. While a session is open, the product stamps each status, priority, size, impediment and notes change to the sprint’s items with that session. The Daily Scrum lists these changes as they happen, under Captured this session. Nobody writes minutes of what moved, because the record writes itself.

Each person also keeps their own block of notes in the session. The product saves each person’s notes separately, so two people who write at the same time do not overwrite each other.

Improvements and feedback go straight into the backlog. The Retrospective has four columns: Went Well, Didn’t Go Well, Action Items and Lessons Learned. While the session is open, an action item becomes a backlog item in one click. Stakeholder feedback on the Sprint Review screen converts the same way. The new item’s description names the session it came from. An improvement then waits in the same backlog as the product work, not in a document that nobody opens again.

Accountabilities, not a permission maze

The Scrum Guide gives a project one Product Owner, and so does SimpleScrumTools. The Product Owner belongs to the project, not to a team. Only the Product Owner can cancel a sprint, and questions asked on backlog items go to them.

Access follows the same plain model. Roles grant capability bundles, and there are eight of them, from View to Manage the organization. A Scrum Team has at most one Scrum Master, and every other member is a Developer by default. A team role applies only to that team’s sprints, sessions and items. Outside the roles, a per-person override on one project is the only way to give or take away a single bundle.

What we left out on purpose

A Scrum-native tool is also a smaller tool. SimpleScrumTools has a fixed set of four item statuses and no custom workflows. It has no burndown or velocity chart, no time tracking, and no custom Retrospective templates. The Scrum Guide requires none of these. Each of them adds a choice that a team must make and maintain, and each choice pulls attention away from the Sprint Goal.

If your team needs a tracker that fits every process in the company, a general-purpose tool is the right choice. Perhaps your team wants to run Scrum as the Guide describes it, with a tool that supports the framework. I built SimpleScrumTools for that team.

See it for yourself

The fastest way to judge a Scrum tool is to use it. Start with the live demo. When you are ready, create a free account for your own team, or compare the plans. If Scrum itself is new to you, start with part 1 of this primer.