A Way of Participating in Software Development

A software development process
is a structure imposed
on the development of a software product


  • Communication: Building the right thing
  • Triage: Allocation of Scarce Resources
  • Planning: Timelines and Reports
  • Organization: Developer Focus

Maximizing Productivity


Mini-model of Software Development


Expanding the Model


A tortured analogy?


What is a Ticket?

It's also known as an issue

It's an actionable description of a unit of work to be done

Software Development Methodology

The process of turning tickets into software.

60 years of practice and research have produced dozens of methodologies



This is how NASA put astronauts on the moon.*



Throwaway Prototyping



Watercourse model

Ticket Triage


Planned Work Week



A collection of tickets that will be resolved and deployed to production as a group

Generally a release has a single focus on a specific functionality or fix

Upcoming Releases

Releases overview

Software Releases vs. Marketing Releases

  • Releases in this context mean the software is available in production
  • A Marketing release involves communicating the software release to customers and providing customer access

Process Theory Informs Ticket Participation

Model purpose
Model purpose2


  • Ticket Management System
  • Contact anyone from dry lab for assistance with account
  • Although normally styled JIRA, the product name is not an acronym, but a truncation of Gojira, the Japanese name for Godzilla

Comments, Descriptions, Notifications, Priorities, Status, and more!

Linnaeus Torvalds Ticket Classification System

Bug An error in the software, it does not work for intended use
Story (aka feature) A new feature of the software, it did not do this before but we need it
Task A unit of work that needs to be done, but does not materially alter a software system's behavior
Epic A bunch of tickets masquerading as a single ticket

Bug vs. Feature: A matter of judgment

Bug vs feature

"We could, for instance, begin with cleaning up our language by no longer calling a bug a bug but by calling it an error. It is much more honest because it squarely puts the blame where it belongs, viz. with the programmer who made the error." - Dijkstra

Authoring Tickets

Is it a bug or a feature?

Different approaches, driven by underlying purpose and context

Common theory for both

It's OK to get it wrong.

Consider your audience, in the context of our process.

Creating Bug Tickets

Create a bug issue everytime you encounter error, right away!

A new ticket is always the first step

There is always one, and only one, goal when fixing a bug:


What information is required to reproduce the error?

  • The environment where it occurred
  • The objective of the user when error was encountered
  • The url where the problem occurred
  • Steps and state of the surrounding processes
  • A screenshot
  • Error message

More or less information should be included based on your judgment of what information would be necessary to reproduce the error

Mode bug ticket

Creating Story Tickets

When new functionality is known to be needed and has been defined

When drafting a story ticket, the goal is always to make the ticket:


Actionable Story Ticket

Remember the audience, what information would the developer need to actually build this.

User StoryA narrative story describing who the user is, what their goals are, and what activities they will do with the software to reach those goals.
Visual Mock UpsA sketch, wireframe, or image illustrating a possible interface solution.
Detailed DescriptionA flowchart or step by step narrative describing inputs and outputs of the software.

Ticket Species: A Judgment Call

Story The new functionality can be clearly defined, meaning that all information required for the ticket to be actionable is known.
Epic The general idea behind the new functionality is known, but the details are not yet known.

It's OK to create unactionable epics for features, for purposes of communication, brainstorming, and refinement.

DNA as Tickets Analogy

Depending on the feature, this can be a lot of material: every detail.

Recall what happens to protein expression if DNA is missing essential codons.


In reality, the developer just fills in the gaps with to the best of their ability and common sense. Sometimes this works out great. And sometimes ...



Avoid assuming that the developer has common sense.

Developers will only know what you tell them about a specific problem domain.

Watercourse model3

Key Point

Bug Tickets: Reproducible

Story Tickets: Actionable

Key Point

This is a learning process, it's OK to make mistakes.

return to blog