Inside Exoweb: Writing Tickets for Scrum
Tuesday, June 24th, 2008In software development, the ticket plays a central role in the development process. In Latour’s terms, the ticket is a non-human actor which carries a message. More generally, it’s a virtual or real object which contains a description of a specific task or a group of tasks. Most tickets are part of a larger project. A project is thus broken down into a number of ideally independent tickets which can then be implemented by the individual developers. In a projects, the final product’s implementation is the sum of all of its tickets.
Many books and papers on agile software development advocate the use of user stories for requirement specification. Wikipedia defines user story as follows:
“A user story is a software system requirement formulated as one or two sentences in the everyday language of the user. […] The user stories should be written by the customers for a software project and are their main instrument to influence the development of the software.
User stories are a quick way of handling customer requirements without having to elaborate vast formalized requirement documents and without performing overloaded administrative tasks related to maintaining them. The intention with the user story is to be able to respond faster and with less overhead to rapidly changing real-world requirements.
[…] Before a user story is to be implemented, an appropriate acceptance procedure must be written by the customer to ensure by testing or otherwise determine whether the goals of the user story have been fulfilled.”
How are tickets, tasks, and user stories related? As mentioned before, a ticket is just a container for a requirement description. At Exoweb, we use user stories to define the client requirements. The tasks are subsequently defined by the developers as the individual steps that need to be implemented in order to fulfill the customer’s requirements for a user story. There are several things we can learn from Wikipedia’s definition above:
- User stories are requirements written in every day language
- User stories should be written by the client
- Every user story should have it’s own definition of “done”
The literature insists that user stories should be written by the customers. Our own experience, however, showed that the quality of the user stories improved considerably when the client was assisted by some members of the development team. Currently, we organise an additional meeting a few days before the sprint meeting, in which the project manager and the team leader are preparing the tickets for the next sprint together with the customer.
User Stories in Detail
In User Stories Applied Mike Cohn presents a formal approach to writing user stories. He suggests the format:
“As a [role] I want [something] so that [benefit]”
For example:
“As a visitor of the website I want to be able to filter search results by additional keywords so that I don’t need to look through a large list of possibly irrelevant results.”
Why should agile teams care about user stories? The main reason is because user stories encourage communication and are written in a language that both, developers and client can understand. A user story should be precise enough for the client to express what he wants and for the developers to estimate it’s complexity. For a more detailed explanation of the difference between user stories and use cases, check out this article.
The Ringier team at Exoweb uses estimation poker for breaking down user stories into tasks. Estimation or planning poker is an excellent way to learn more about the details of a user story. Each developer is asked to estimate the user story and to explain his estimate. This encourages consensus among developers and it allows the team to agree on the necessary technical tasks which need to be implemented for a specific user story. As the client is present during the poker, the team members can ask questions to avoid misunderstandings. When using estimation poker for planning tasks, it is very important to avoid anchoring:
“Who ever starts the estimating conversation with, “I think it’s 50 days” immediately has an impact on the thinking of the other team members; their estimates have been anchored, i.e. they are all now likely to make at least a subconscious reference to the number 50 in their own estimates.”
Defining “Done”
As we have seen in the Wikipedia excerpt above, every user story should be completed with a definition of “Done”. This definition of is ideally a description of the demo the client wants to see at the next sprint meeting. More generally, it’s an agreement between the development team and the client in which the client defines which conditions a ticket has to fulfill in order to be considered “Done”. At Exoweb, we additionally use this definition as a base to define the functional tests for the ticket.
Ticket components
At Ringier team, each of our tickets consists of the following elements:
- Title, Ticket Number
- The developer estimate
- One or several user stories
- Definition of “done”, including demo procedure
- A list of “technical” tasks defined by the developer
- Screen shots of screen designs should be included if available
Ideally the ticket should contain all information a developer needs to start working on a it, and all possible impediments should be solved before a ticket is accepted for a sprint. This allows to minimize the risk of the implementation differing from the client’s expectation. Additionally, it facilitates the developer’s work because he knows exactly what he has to do in order to complete a ticket, and it enables the project manager to decide when to accept a ticket for demo for the next sprint meeting.