If you look at this diagram of a typical "SCRUM" process, it’s no wonder that nobody bloody understands it.

I mean, "Respect"? "Focus"?

Those are all nice things, but guys — can we please simplify the process down to the bone, and remove any obstacles?

Before we dive in, lets first agree on what is considered a "good" process — i.e. what are the desirable tenets of an ideal software development process?

The process described below addresses all of the above goals, and we will point out which of the goals is specifically provided by each process feature.

At the heart of this is a process known as a "Story Writing and Estimation". There are numerous resources on the subject.

If you never participated in a well-oiled story estimation meeting, you may be thinking that this is an unnecessary overhead, or even a bureaucracy. If you are coding alone and your work does not affect anyone, then perhaps you are right. And yet, most of the time engineers working in teams, or groups, i.e. not in isolation — must constantly communicate. For the team to be effective everyone needs to be on the same page. Which in turn requires an effort of some sort — sprint planner just happens to be one of the most effective ways to address multiple desires and goals listed above at the same time.

With everyone working remotely during the COVID pandemic, it becomes even harder to keep everyone on the same page. Working remotely requires an additional effort to keep everyone in sync, which makes this already very important meeting absolutely critical to the overall success.

Lets review how this works, and why it solves several of our goals mentioned above.

In order to properly estimate a story, software engineers must:

The planner not only puts everyone on the same page with respect to the above points, but also lets the team members validate the chosen implementation approach, whereby avoiding unpleasant surprises later. And it works, most of the time 😂

With this in mind, let’s get to it — in the next section we’ll describe this process in detail.

We start by digesting often ambiguous requirements in a form of user stories written by a PM or someone within the Product Organization. It is critical that all stakeholders and ticket authors are present at the planner and can answer questions and negotiate solutions.

While generally Planner is NOT a design meeting, in reality quite a bit of ad-hoc design does happen during story estimation. This is because engineers must visualize the implementation in order to be able to accurately estimate a story. This is OK.

But sometimes the story can be so complex that it is not possible to come up with a quick "back of the napkin" design. In such cases the action item from the planner is a "design meeting" where engineers collaborate on a solution, and when finished — enter it into the ticketing system as one or more implementable and already-estimated stories.

The identified need for a design breakout can be represented in the Tracker by a "chore" — eg "Break down approach to building a Flux Capacitor".

Sprint Moderator

Spring Planner, much like other meetings, requires a moderator. Ideally, this is the technical lead of the team, or any other engineer, possibly on a rotating basis. The moderator has several key responsibilities and so its important that the moderator understands them.

For the list of common mistakes and pitfalls during the Planner, please refer to the section below.

Moderator’s primary goal is ensure the following protocol occurs for each story.

Teams that are not very experienced in a group story estimation will need more time initially to get used to the process. After a few weeks they’ll move a lot faster forward.

Here is an infographic that depicts the above described process:

Estimating stories requires a consistent point system. Ultimately it doesn’t matter what it is, as long as it follows two principles:

The point system that seems to work well is the following:

This point system generally implies that a single engineer should have a velocity of 15 per week. As the team works through sprint after spring, it’s important to make sure that engineers are not too far apart based on their velocity because if they are, it means that estimations are likely inconsistent.

Story estimation and the discussion it yields lead to a more disciplined and rigorous approach to software engineering, while a process that lacks this meeting tends to be more ad-hoc and less predictable.

Pivotal Tracker and other project management tools are able to compute an average velocity for individual engineers and the entire team as a whole, which translates to accurate scheduling of features based on the priorities, not on "can you please work faster" culture. Being able to see when each story is scheduled to be worked on facilitates the transparency listed as a goal, thus building trust between engineering and the rest of the organization.

It also implies accountability — if someone under-estimated a story, or is falling behind for other reasons, the PM and project managers will see it sooner than later, making it possible to reprioritize other stories or adjust the resource allocation. In any case a potential slip in delivery can be remedied early enough in the process to be fully addressed.

There are different schools of thought here, but in my opinion it should be possible to retroactively update a story that was incorrectly estimated with the more accurate estimates. This enables more accurate calculations and predictions.

However, its possible to allow or disallow this based on the reasons:

Group estimation practice encourages individual accountability.

Why? Because if I say that it takes me one day to complete given work, and then it takes me three days — I am going to raise my hand and say that I made a mistake and underestimated the story. Because personal accountability and integrity is on the line.

If, however, the estimate was passed down from someone without my explicit participation, I am less motivated to commit to it, since I didn’t sign off on it, and it was forced down on me. Because of that — don’t expect me to adhere to it. And this mentality breaks the velocity calculations and makes predicting deliverables difficult.

There is lots of good literature on this subject, such as this one.

A very quick summary of common planning mistakes based on the personal experience:

The below list of Anti-Patterns is perhaps one of the most valuable parts of this document.

PT pricing is unfortunately weird:

Does this make any sense to any of you? It sure doesn’t to me.

Here is a animated screenshot of Pivotal Tracker’s Backlog and Icebox in action.

Pivotal Projects integrated with Github support automatic updates to the corresponding stories based on a commit message syntax:

In addition you can paste any number of pull request URLs into the story to link it to the code changes.

A recent feature change to PT support any number of review types, for instance: Security, Performance/Scalability, etc. A ticket can be reviewed and either accepted or rejected by each reviewer.

PT supports cross-story references for stories blocked by other stories.

Story info pane showing story ID, link (click to copy), delete button and other properties.

In this section we’ll describe the story states as they are in Pivotal Tracker, and what they mean for us in our process.

When you first create a story, it will be created in whatever the column you chose to click on "+". If you create a story without any column selected, the story is added to the Icebox.

You can drag stories out of the Icebox and into the Backlog. In which case, they begin their life as "Un-estimated and Un-started".

The following are the states of a Pivotal Tracker Story, with explanations:

The meaning of "Delivered" is somewhat open for interpretation, and can be used differently by different teams.

For instance:

In other words, the Delivered state is somewhat open for interpretation and can be adapted for your what works for you and your team.