You don’t have to be a developer to create well-defined tickets! Yes, I’ve said it! It’s how you communicate your idea to the developer, leaving nothing to imagination.
There is another human being on the other side of the ticket, the developer. He needs to understand what you mean. If your ticket will be vague, this will be exactly what you get after he develops it. You will waste a lot of time on back-and-forth communication with the developer. Finally, you will probably get something you didn’t request or had in mind.
I would like to present two different scenarios requiring the same result. In one scenario, as I see countless times in other places, we will have a brief description. We will see what are the problems with such a ticket. In the other scenario, I will present a better way of laying out requests, thus saving time and getting exactly what you want.
Let’s look at Googles advanced search page:
Hypothetically, we have a request to add a new field to this page, allowing the users to search by city.
The First Ticket Written by Lonzo
We need to add a new field to the advanced search page. The field will let the users select and search by city.
Annnnd, that’s it, I saw this kind of tickets way too many times. The ticket is full of holes. I can’t even call it a ticket. That’s a statement. Doesn’t matter what is the level of the developer, he will have lots of questions from reading the ticket:
- Where do I put this field?
- What’s the label?
- What kind of field is this? Select/Text.
- And so on
Some developers won’t ask questions, they will simply create what they understand. That doesn’t make them bad developers, but in this case Lonzo can get something like this:
The results are:
- The field is the last one on the page — seems out of place.
- The field is a free text field — a better solution would have been a select field.
- The field has no ‘help’ to the right of the field, thus making it stand out and not providing the user any information on how to use the field.
Aside from the UI, nothing explains what the field should actually do when executing the search query thus, we don’t know what the developer implemented. This will make it very hard to test.
The verdict on Lonzos ticket:
It probably took as little as a minute to create the ticket. The time it will take to develop will be substantial.
- If our developer will have questions — Lonzo will need to discuss these. This may be a problem, if both are not co-located, simply scheduling a meeting can take a day. Lonzo may have different tasks on his hands and doesn’t have time. This will delay his ticket development.
- Once the ticket is done —Lonzo may not like placing of the field on the page. This will cause re-doing part of the code to move the field.
- Field has no functionality, the developer thought it will be developed in a further ticket.
- QA is not sure what needs testing — The QA may ask for clarification or test unrelated functionality resulting in unknown behavior deployed in production.
All the points above will add to the development time. It can be a lot of time because of weekends and multiple meetings/massaging back and forth. As a result, Lonzo will feel the development team is not good enough or making his life hard.
The Second Ticket Written by LaMelo
The why:
Following the new service ‘BestCityCoupons’ there is a growing demand for city specific searches from users. We need to add the option to select city name when searching via the advances search. This will attract more users to the Google search engine. As of now all the users that want to search by city are using the rival Bing platform which has this ability.
Scope:
- On advanced search page, add a new field called ‘city’.
- We will place the field beneath the ‘region’ field.
- Add the following help (found to the right of the input field): ‘Find pages published in a particular city’.
- Field type will be select type.
- The user can select any city in the world using this field.
- When executing the query, return only search results coming from this city.
Example of the page:
Acceptance Criteria:
- Following this ticket, we will add a new field to the advances search page.
- The field name will be city.
- Users will select cities in the new city field — we can select any city.
- Search will return results from this city only.
Additional check — Make sure we place the field as shown in the example.
The verdict on LaMelos ticket:
As you can see, ticket number two leaves less to imagination.
In the first part of the ticket, Lamelo defines the why of the ticket. This gives the developer an idea on why do we need this ticket at all. A glimpse at the business side. Lots of good things can come from sharing business side with the development team. We may get a suggestion or an idea from the dev team allowing us to develop faster and smarter. Development team that understands the business side will be more driven to suggest ideas. It is LaMelos' responsibility to listen to the suggestion coming from the dev team, thus making them missionaries, not mercenaries.
The second part is the technical part. LaMelo doesn’t need to be a developer to know how to write this part. His job is to leave as little as possible to the dev team’s imagination. LaMelo defines all the parts connected to this field; where to put it, what label, help and so on. Now, the developer cannot put the field wherever he wants. The developer cannot change the type of the field. This is not to take any responsibility from the dev team, this is simply to make the developers’ life easier with clear cut steps. As you can see, a screenshot is attached to this section too. This is also a great tool to use. It is less obvious here, but when you work with more complicated stuff on the page, such as buttons, visual components, and multiple other moving parts, there is nothing more helpful than a sketch. If you don’t know how to work with paint/gimp to create these mock ups, take an hour of your time and watch a YouTube tutorial. This will improve your tickets greatly. If you know a bit of HTML, you can manipulate the page live via the inspection tool of the browser which I did in the pictures above.
We reach the last part of the ticket. This is the bottom line. The last section is what LaMelo expects to be implemented. We can write all the business points and all the definitions in the why and scope sections. What counts is what we would like to have following this ticket. This section also will be of great help to the QA that will test the ticket.
Who wrote the better ticket, Lonzo or LaMelo?
On the first ticket, Lonzo will spend a couple of minutes to create the ticket. Then, while in development/testing, he will spend lots of time talking to dev team members, answering questions. Lonzo may get the wrong feature or something that he didn’t intend to develop due to poor communication.
On the second ticket, LaMelo has defined the feature the best way he can. The UI should be done exactly as he defined, as he provided exact definitions with a screenshot. The feature will do what LaMelo expects, as both the developer and QA will develop and test what was requested. The time it takes LaMelo to create such a ticket is longer than what it took Lonzo to create his. But, and a big but at that, the developer will understand the vision of the feature better thus reducing time spent on asking questions. The developer may suggest better solutions. You can find gems. For example, a developer may be familiar with the technology used in the hypothetical ‘‘BestCityCoupons’’ service and can provide hard reasons why developing this may harm our company or be useless. The developer may suggest better ways to implement, like allowing to select a city only if a region was selected, thus making the select field options smaller and reducing page loading time.
Can you see the difference between the two tickets? Lonzos ill definitions led to waste of time, incorrect implementation and wrong ETAs. In LaMelos case we get less time wasted due to missing info, better implementation of what is expected and more accurate ETAs.
As Jeff Patton said in the User Story Mapping book
The best estimates come from developers who really understand what they’re estimating.
I would change the sentence to something a bit different but still the same:
The best outcome comes from developers who really understand what they need to develop.
I hope this article will help some of you. Please communicate better and remember, there are people on the other side that need to implement what you define. The better your definitions, the better your product will be.
