Part of the Cloudspace Agile Process is to break large specifications down into feature tickets to assign to engineers. Breaking the specification down into feature tickets allows you to get a real feel for the depth of work involved in each step of the creating a web based product. Taking the time to break down a product into fine grained feature tickets is one of the most important things any product owner can do for their project. Each ticket should be focused and explicit, giving the developer every piece of information they need while remaining as brief as possible .

Writing Super-Amazing(TM) Feature Tickets Will Save You Money

At the beginning of each week we work with our clients in a sprint planning meeting where the product owner and the engineers who will be working on the application for the week go through the tickets for the week step by step. The engineers ask questions and often rewrite some tasks and the product owner can find out if the developers understand everything that goes into the ticket. It is another chance to split things up, reorder tasks, and remain agile. Another reason to write really great tickets is to save money. With a clear ticket it is less likely that an engineer will have to stop and ask a question or think about what the client meant by "add a search bar on the home page". We all know stopping to ask a question breaks that precious programmer flow and it takes a while to get back into the zone.

The Three Key Parts to Writing Super-Amazing(TM) Feature Tickets

• Short, Meaningful Titles
• User Story Based Descriptions
• Clearly Defined Task Checklists

Short, Meaningful Titles

The ticket title is the thing seen most often by the greatest number of people involved in the project. It should contain enough keywords to describe the gist of what the ticket will accomplish without being too long. Generally 10 words is way too long and you want to try keep it around 5-7. For example purposes suppose we need to write a ticket with tasks to move a few links around in the header, change the text of one link, change the style of the navigation bar, and change the spacing a few other header elements.

Bad Ticket Title: "Display Change"

This one is too short and it isn't specific enough.

Better Ticket Title: "Header Updates"

This one is better because at least it nails down the updates to a specific section of the page, but it still doesn't describe the tasks very well.

Super-Amazing(TM) Ticket Titles

• Header Updates: CSS, Links, Spacing
• Header Styling and Link Clean Up

These title communicate more about what is going on inside them than the other examples. This information helps everyone involved to quickly recognize each distinct task by the titles listed in the ticketing system.

User Story Based Descriptions

Ticket descriptions should be several sentences but not several paragraphs. They should describe the business value of the feature and generally how the user will interact with the application if possible. If you have screenshots or mockups that always helps, attach them.

Let's flesh example title from above with a couple of descriptions.

Bad Ticket Description: You'll be moving some stuff around in the header, see tasks listed below.

This isn't a great ticket description because it doesn't tell us anything about why we are making the change or about how the changes affect the application's users.

Better Ticket Description: Header changes to make things cleaner and easier to find.

This is a little better because it tells us part of the "why"-- that things need to be easier to find, but it isn't enough.

Super-Amazing(TM) Ticket Description: Users are having trouble finding their "Account Settings" so we're reorganizing the navigation to make things easier to find. Account Settings will become a new top level navigation item and we are also making some changes other small changes to the header to clean up the look after reorganizing the links.

This ticket description communicates not just the "what" but also the "why". Giving engineers insight into what you are trying to accomplish gives them a greater opportunity to understand the project on the whole.

A Second Description Example

Bad: Change the page settings for external urls, combine the domain and url and then make the external import option a checkbox.

Better: External urls are confusing here, let's find a new way to handle this form by combining the URL into the second text input, eliminating the third text input, and changing that to a checkbox.

Super-Amazing(TM): We need to allow users to enter full URLs that are outside the main url of their project and having two URL fields to do this is confusing. We'll be changing the way the second form field with the page URL works so that it covers both relative and absolute URLs. We'll then change the third field into a checkbox to trigger the import.

Clearly Defined Task Checklists

Having a good title and description helps keep the entire group involved and on the same page as you build a product but when when it comes to ticket completion speed, tasks checklists really are the biggest factor. Capturing each aspect of the change you want made as a specific task makes sure that the engineer knows each thing that you expect to have changed. It should also help the product owner think about exactly what they want to implement.

Good tasks are very specific. If a task is about adding a link to the page, be sure to specify the destination URL, the link text, and exactly where it belongs on the page. Don't just say to add a link for "Search" to the navigation, tell the developer to put it after "About Us".

Bad Task Checklist

• move account settings out
• make it my projects
• tighten up nav spacing
• bring the logo down

There is a lot of room for interpretation in this list. Move the settings to where exactly? Tighten up-- do what? How far down do you want the logo? Even if you've attached a mockup or image that shows exactly where everything should be, this list is still pretty bad.

Better Task Checklist

• Put "Account Settings" in the navigation as a top level item
• Change "Projects" to "My Projects"
• Remove some padding from the navigation elements
• Align the logo with left text

This checklist is better. Paired with a good mockup, an engineer would probably fly through this simple ticket. The thing is, tickets aren't always coded by the engineer you plan to have code it, so it is often good to go the extra mile to provide good specific details in the task checklist. An engineer may not notice all of the same things in a mockup unless the mockup has notes on it.

Super-Amazing Task Checklist

• Move "Account Settings" to a top level navigation item after "About Us" from out of the "Projects" sub navigation
• Change the "Projects" tab on the navigation to "My Projects"
• Remove padding from the navigation elements so that the right edge lines up with the right edge of the sign out link, check ie, chrome, firefox, safari
• The logo is showing 15 pixels to high in safari

A Full Ticket Example

Bad Ticket

Title: Move Everything Around

Description: Move a bunch of links around so they are in a bar on top of the mockup pane so the site looks better, see the tasks.

• put the page selector in the bar first
• on the other side put the page settings link and the add a new page link

Better Ticket

Title: Mockup Pane Header

Description: Add a bar to the top of the mockup pane and put links and page selector in it.

• Add a grey bar above the mockup pane
• Put the Page Select Menu on the left and bring the project URL into the select menu
• On the right side put the Page Settings link and the Add a New Page link from out of the page selector

Super-Amazing(TM) Ticket

Title: Create a Header Bar Over the Mockup Pane

Description: To make room for the set of navigational tabs at the top right we want to create a bar at the top of the mockup pane to hold form controls that are currently on the top left of the page. These settings fit well in this bar since they are directly related to the current page showing in the mockup pane.

• Add small Bar that connects directly to the top of Mockup Creator Pane pushing it down, use the same background Grey as the "Page Elements" tab of the accordion when you are not hovering over it, use minimal padding
• Put the Page Select Menu from the top left of the page in new Bar on the left side
• Move the Project URL from the top left of the page into the Page Select Menu so that the full URL for each page shows in the select menu
• Move the Page Settings link from the top left of the page into the Bar on the right side
• Move the "Add A New Page" link out of the Page Select Menu and into the Bar to the right of Page Settings

Wrap Up

In startup world, speed is everything and often the immediate concern is taking a new idea to the Minimum Viable Product stage. Super-Amazing(TM) feature tickets are crucial to being able to quickly iterate the idea into a working product. Great product owners have a knack for describing incredibly complex systems as a series of simple interactions and this is the essence of what we try to capture in every ticket-- the simplest action that makes the smallest part work. When planning features be sure to take a careful look at the tasks that make up each ticket. Are some of them just "nice-to-have" features instead of core pieces of the product? Do any stick out as particularly complex? If you can, pull them out and put them into their own ticket. Pare down the tasks in each ticket to the essentials to find the core product.