Organizing for Agility and Success (Part One)

I have led, organized and participated in a number of successful software projects using Pivotal Tracker since 2008. These projects ranged from the small ($20k) to pretty large (over $2M) in terms of budget and from team sizes of 1 up to nearly 20. I have also had the opportunity to look at projects organized by others. In my experience, every project using Tracker could benefit from better organization.

In this post, first of a 2-part series, I describe how to use some of my successful techniques to improve your use of Tracker and hopefully save you a lot of trouble.

Pivotal Tracker Requires Technique

Like most project management tools, Tracker is pretty flexible. It is strongly Agile in its approach and it attempts to lead you in the right direction through its opinionated design. Effective use of Tracker however requires disciplined organizing techniques that are not immediately obvious.

If you start a project off with a well-organized backlog, the contributors generally pick up many of the techniques quickly. Over time however, discipline slips and every project becomes somewhat "messy." Rigorous application of technique is required to put things back on track. A messy project wastes everyone's time, does not provide a clear picture to stakeholders of what is going on, and quickly becomes a drag on the value-creation process Tracker is supposed to facilitate. Frustration results. Team morale and productivity suffer. To avoid this situation or find our way out of a mess, let us review Tracker with attention on how to use each element properly.

Agile to the Core

Tracker provides a loose framework for planning and tracking value delivery during a project lifecycle. Tracker is meant to replace a crude but effective paper-based technique using a wall comprised of Post-it notes organized into columns. This works when everyone is in the same room. Unfortunately this describes about 10% of modern software projects.The Post-it notes system is in turn based on the Kanban style of "demand-pull" production pioneered to great success at Toyota. Learn more about that and you will grok the Zen of Agile tools like Tracker. Used correctly, Tracker helps contributors see the big picture while staying focused on the work in front of them. It helps set the cadence for value delivery and tells managers and stakeholders when valuable features will be delivered or when milestones will be achieved. Used correctly, Tracker helps project owners make the tradeoff decisions essential to any development effort. Accordingly it provides the framework for developers to communicate with stakeholders about schedule and difficulty with a minimum of ceremony or fuss.

Elements of a Tracker Project

Tracker projects are comprised of the following basic elements:

• User stories
• Bugs
• Chores
• Milestones
• Epics

Tracker helps you organize the foregoing elements into three basic columns:

• Backlog - Organizes value scheduled to be delivered in future iterations
• Current - Contains items to be delivered in the current iteration
• Icebox - Organizes items that are contemplated or anticipated, but not yet scheduled

Each of these require proper organization to be effective. Proper understanding each element and how to work with it helps keep a project organized.

User Stories

User stories represent chunks of value that may be delivered to a user. People often use the word "feature" however, confusion on this point leads to problems. Value is the thing being delivered. The feature is a means to an end -- the end being value creation and delivery to users. We keep our eye firmly on value delivery by naming our features well and elaborating on the value in the description.

Story Titles

Always consider who is the primary beneficiary or user of the feature. Then take care to name the corresponding story in the correct form: <subject> <verb> <object> [optional modifier].

The subject should be a "type" or class of user. Examples:

• Author
• Admin
• Developer
• Reader
• Visitor
• Editor
• Approver
• HR
• Employee

The verb should always be in the present tense.

Examples:

• Creates
• Clicks
• Sees
• Sends
• Purchases
• Completes
• Selects
• Changes
• Edits
• Submits
• Approves

The verb should be as plain as possible while still being specific. It should be something that the user would understand. The object will refer to terminology -- generally informational entities -- specific to the application. It should also be something that the user would recognize or understand.

Examples:

• Message
• Payment information
• Work order
• Invoice
• New client
• Credit card number
• Employment status
• Error
• Existing contact
• Location marker
• Street address
• Phone number

Use an optional modifier to add relevant detail. Projects tend to increase use of the modifier as the project matures and requires greater specificity.

Examples:

• On the account page
• In the payment form
• On the landing page
• In the signup form
• During confirmation step
• While entering a new contact
• From admin dashboard

Keep the optional modifier minimal. Each user story should have a short title, that contains just enough information to avoid ambiguity but which is easily scanned visually from the list. 3-8 words is usually enough. Save the detail for the User Story Description.

Descriptions

Well formed User Story description fields should contain:

• The motivation for the feature
• The acceptance criteria

Any additional clarification or requirements describe the value that the feature delivers to the user if it is not obvious. This serves several purposes. First, it helps keep the design user-centered by ensuring that we are delivering something valuable to someone. A surprising number of features creep into backlogs which nobody can seem to justify when pressed. Second, clarifying the motivation helps developers to avoid having to guess about what is intended. It allows them to "fill in the blanks" without triggering extra, expensive communication.

Lastly, the motivation of the user story keeps the developer attuned to users' desires and to value delivery. Manipulating intricate software abstractions all day often causes developers to lose touch with the meaning of their work. Intrinsic interest is a powerful motivator but many developers benefit from an appreciation of how their work connects with and benefits users. Teams suffer when they lose sight of the purpose.

Acceptance criteria can be a simple statement of what the user should see or be able to do if any elaboration is required above that described in the title. If no acceptance criteria is provided, then a minimal interpretation of the title will suffice. Developers may do the simplest possible thing that satisfies the title of the story. If you expect more than the minimum, write more. If you use Cucumber or related Gherkin style Behavior-Driven Development (BDD), place your full cuke for the story in the description. A bulleted list of clarifications, additional requirements or implementation notes may be placed at the end of the description.

Points

Teams use a point system to estimate the relative complexity of User Stories. Point systems in Tracker can be powers of 2 (0, 1, 2, 4, 8); linear (0, 1, 2, 3), fibonacci (0,1,2,3,5,8) or custom. We favor Fibonacci. Complexity is relative but you have to start from somewhere. I generally think of a 1-point story as something I can accomplish in an hour or two. A 2-point story might take me all morning. A full day of work on user stories might result in delivery of 4 points. 5 point stories will take more than a day.

Eight point stories are a red flag. It means there is enough complexity in the story that it obviously will take more than a day or two and represents significant schedule risk. It may contain unbounded tasks and hidden sub-projects which can torpedo a schedule and stop a team in its tracks. These should be broken down into smaller stories and/or converted into an Epic. Often the point total of the smaller stories will be greater than 8 points.

If you typically work in pairs using some form of pair-programming, then the points should correspond to what a pair can deliver in those time frames. There are no absolutes -- points are relative to the team and project and each team will settle on norms that work for them. There are two rules here with points that teams and Project Owners ignore at their peril:

1. Workers estimate, not managers.

The people who do the work should be the ones to estimate. In no case should a manager, non-technical person or the project owner even if she is technical, perform the estimation. If the project owner is also doing development she may choose to estimate only the user stories she intends to implement herself.

2. Do not change point totals once work has started

If you or your team start to change point estimations after work has started, or worse, after work is delivered, then you open the door to "gaming the system" and losing the predictive power of a well estimated backlog.

Labels

Correct use of labels helps bring sanity to a Tracker project. Labels will often refer to a component of the system. These can be used to indicate preferences for story selection so that an individual or pair may work on a series of stories related to a single component of a system. When a single word appears or will appear in many user story titles, it probably should be removed from the title and become a label. Labels are also used to group stories into Epics comprised of related features. This is perhaps their most important function.

When creating an Epic, Tracker defaults to making the entire title of the Epic into a label. Do not do this. Assign a short, sensible label to the epic. Labels should be one-word, short and specific. If you need more than one, use a common, easily understood acronym. The goal is to render a long list of user stories easily scannable by the eye and make it possible to quickly navigate to a filtered list of related stories. Try not to use specialized vocabulary. Example labels might be:

• cms
• registration
• onboarding
• checkout
• search

You may include more than one label. Two is common. Three is rare. If you need more than three labels on an item, you might have a problem with your labeling scheme. Do not create a label that will only be used once or twice. These create noise and do not add value. In this case, the word belongs in the title or elsewhere in the description.

Tasks

Tasks are developer-oriented lists of things to be done in order to deliver the user story. This is where programmer-talk goes. If any decisions need to be made put them in the tasks like so:

Decide whether to combine auth subsystems or keep them separate

Or

Choose the best of the three available gems (x, y, z) for this

During estimation, a developer who is thinking through how a user story might be implemented, may come up with a sequence of tasks they would need to complete to deliver the feature. They should put them in at that moment so when they or another team member begins work on the story, perhaps weeks or months later, they will have a quicker time understanding the thinking behind the estimation and perhaps the true technical scope of the story.

Other Stuff

Requester and Owners are self-explanatory. These are the people who will be notified automatically regarding the status and conversation around a user story.

Bugs

Internally in Tracker, Bugs are simply user stories that do not have points. Bugs can be sourced from a support ticketing system, input by the project owner, or frequently they are entered by the developer in the course of working on the system. Bug titles do not have to be as strict as story titles but adhering to good conventions will help a lot. Include who is affected by the bug and what task they cannot do or what they see that they shouldn't see, etc.

In the description, describe the method to replicate the bug if you can and state any workaround that may exist. Use labels effectively. Label the bug with the component involved and the Epic it may relate to if any. If a bug has a financial impact, try to state that in the description and Label it with a tag indicating such. Examples:

author cannot cancel the publish dialog

error appears when entering phone numbers with spaces on profile page

If a specific error code or message appears, include it in the description. If a screenshot is easily obtained, attach one.

Chores

Developers frequently populate a Tracker project with an abundance of Chores. This results from thinking in terms of tasks or "things they need [or want] to do." Chores should be reserved for those things that do not deliver value to a user. If a chore can be restated in terms of the value to the user, it should be converted to a User Story and treated as such. Bugs and stories go through an acceptance workflow wherein the Developer delivers the item for acceptance and the Project Owner typically accepts the item as complete or rejects the item. Chores do not follow this cycle. They are accepted by the developer or requester. It may be difficult or impossible for a non-technical Project Owner to know whether a chore is complete.

Refactoring and Technical Debt

Cleaning up technical debt can be entered as a chore. Developers frequently create Chores in this way to remind them of things they are deliberately not doing in order to deliver a feature quickly. In general, I prefer to clean up technical debt, at least in small ways, while working on User Stories. I consider that to be just part of the work to be done. When you break it out as a Chore in the Icebox that seems not to deliver value to a User, it will never get prioritized. Do as I do or encourage your team to refactor as they go and you will keep a steady pace of value delivery, unhampered by a growing mountain of technical debt. I hope this information is helpful. In part 2, next week, I will describe the techniques I use for organizing the Icebox and the Backlog as well as the workflow around Acceptance of items.