One of the core and most important values in the agile manifesto is “Individuals and interactions over processes and tools”. Tools like JIRA can provide value, but the value they provide comes from facilitating interactions, never from replacing them. Another of the principles from the agile manifesto is to value “Working software over comprehensive documentation”. JIRA tickets are not a deliverable, and if you have a JIRA board that is 100% accurate with beautifully laid out rich descriptions in every ticket, there is no actual value added – and this counts for nothing without executing on the underlying customer needs and delivering!
Something that all teams who are making their first steps on the agile journey need to remain mindful of is a tendency to revert to the familiar. JIRA appears to offer a way to formulate detailed plans – and to a team nervously stepping away from the familiar waterfall approaches of big design up front and intensive planning, this can be a dangerous temptation. JIRA can be treated as a place where analysts or product owners can work in isolation, populating tickets for the (separate) delivery team to pick up. At a push, this can work, but it’s a shame to miss out on the opportunities and benefits that can come from closer collaboration. The more rigid the hand-offs between different specialisms is, the more distance is potentially created between the product people wanted and what is eventually built.
For small, straightforward tickets – like bug fixes – a JIRA ticket can be a fine way to kick off a piece of work. There is a relatively well known set of information that can describe what is needed, such as a set of steps to reproduce a specific issue and observed behavior, and a description of what the desired behavior should be. Even in this example, it may be preferable to capture less information in the ticket, on the condition that a conversation happens instead. If the person who finds a defect speaks directly to the person who will fix it, a couple of things happen. Firstly, the fixer gets a chance to ask whatever questions they want to exactly pin down the problem in a way that makes sense to their personal model and interpretation of the system. Secondly, and arguably more importantly, a dialogue is opened, which can create empathy and bonds, and with that a culture of trust and assuming the best in people.
I frequently observe that teams that have rigid handovers between disciplines are also the most prone to frosty relationships, perhaps even blame. The person who writes the ticket assumes they have done so infallibly, and thinks worse of the delivery team if they aren’t able to follow through in the way that was imagined, while the delivery team can resent feeling like they are having over-specific “orders” transmitted to them in tickets, which reduces their role to “code monkey”, and feeling like a machine to grind out work, all of which can be extremely detrimental. Equally, if the ticket is delivered, and then the writer wants to tweak the behavior after, based on feedback of using the result, it can create a feeling that the delivery team are having their time wasted by indecisive product owners.
In the best teams I’ve worked with, JIRA tickets simply represent a conversation to be had between a product owner and delivery team. The ticket contains enough information to introduce the problem, as a starting point, but there is no need to go beyond this. When a delivery team are ready to pick up the ticket, the product owner makes themselves available, and a conversation is used to pad out the details. This might be “Three Amigos” style examples, as described in Specification By Example, where the business expert, developer and quality analyst work together to write executable specifications. It might be a series of sketches, that help illustrate a workflow. It could be anything, so long as it’s a useful medium to the people specifically involved – and it’s impossible to know what that is up front. Communication is a constant two-way flow of information, with each party responding to subtle hints about what the other is taking in, as well as the content itself. It can be great fun to work through a feature together, and often the feature that is defined as a group will be enriched by contributions from all involved – that would never be heard if a hand-off in a ticket management tool is the adopted process.
One of my favorite experiences of this was working with a product owner who had a really good idea of what he wanted, but had previously felt he had to self-censor, to break his vision for the product down into JIRA ticket sized chunks. We fully integrated him into the team, and he sat with us while we spiked out some prototypes. This was very much a 2-way learning exercise – he gained an insight into the kinds of things the team were capable of, and a measure of how long things took, and crucially, saw first-hand the level of information that was effective to work with. We meanwhile learned far more about the actual domain and how the product would be used, and why we were being asked for these things. We spent a couple of weeks prototyping, in a cycle of a couple of hours enhancing the code, followed by a half hour demo and discussion – and the results far surpassed what the product owner had felt he could ask for. At every junction, he was able to see and feel the results, and constantly adjust the direction as we went. We were able to throw around “what if’s” and “maybes”, and experiment as a group with even the craziest ideas. In the end, about 90% of the JIRA tickets that had been outlined before were scrapped, in favor of a heavily revised set of goals. We maintained a close working relationship with the product owner throughout the project’s lifecycle, and never again even bothered with tickets, estimating or any of the ceremony – we simply replaced this with conversations!