When I joined my team, it was common for our Technical Project Manager to write up tickets, and then during a refinement session with a few devs on the team, we would review and dictate changes to him which he would write down. This is how most of our tickets were created and how we captured technical details to guide the implementors.
Words cannot express how much I hated this. First, Technical details of a ticket is not something that we can be verbally dictated easily. As a Software Developer our lives revolve around a wall of text. So, having to articulate tech requirements verbally for someone else to write down was awkward and prone to error. Second, software architecture is something that needs to be thought through, and should not be the result of improv. A meeting that spends five minutes per ticket is not conducive to a good ticket.
I was not alone in my disdain for this approach, so I worked with some of the leadership on my team to create a new approach.
So, what is the solution?
I can envision a lot of different ways to solve this, but this is what we did.
Everything starts with product owners. They The product owners do their thing, write up a product brief of sorts, and pass the initiative off to the developer team. This is where we step in:
- Research: The manager or TPM create a Spike Ticket. This is a ticket linking the brief and including some other relevant details. The acceptance criteria mentions the developer should write up a Request For Comment (RFC) document.
- Write up an RFC: A Developer on the team takes on the ticket. IT doesn't have to be a lead or architect, it can be anyone on the team. They read the product briefs and related documentation and write up the RFC. The RFC will summarize the product ask; and detail how we plan to solve it. This write up may include database diagrams, flow charts, and changes to code. Often the RFC will include multiple approaches. The dev should suggest their preferred approach.
- Review: The team takes time to review the RFC And discuss. Often this starts asynchronously, with people leaving comments for clarification. It moves to a meeting, often starting with a silent read through, and then discussion around the various approaches. Sometimes proposed solutions are mixed and matched and a new approach needs to be documented.
This process may include external stakeholders, such as the product owner or members on other teams.
- Modifications:If changes are required to the RFC, the dev owner will make those changes, or document the new proposed solution. Another review, often shorter, will occur.
- Ticketing:With a solution decided upon then the dev owner will split the work into tickets. The ideal goal is to get a lot of small iterative tickets that all come together to make a working solution. Depending on the size of the initiative, this could be months of development, which means a lot of tickets. We'll often put together an org chart to keep track of tickets and their dependencies and what work can be done in parallel. This is a great visual indicator to the TPM or Team Manager or Product Owner on the scope of the work and how much can be worked on in parallel.
- Pre-refinement:With the tickets written, the RFC Writer, and a few other team leads will do a pre-refinement meeting. We'll review each ticket, and the org chart. This is a small meeting where we are making sure that the actual tickets cover all the work required and we are not missing any important business requirements as we moved from RFC to tickets.
- Team Refinement :Team Refinement comes next, where the full team reviews and points the tickets. Ideally we are not making any changes to the tickets at this stage. The RFC Writer will often walk the team through each ticket, and explain the importance of where it falls in the larger architecture scope.
From here, the tickets are ready to be added to our next sprint.
Why does this work?
With this approach, all our thinking is in the RFC phase--ideally--and when it comes implementation time we are off and running without much debate. It makes development more effective.
With this approach it is also important to spread the RFC work to everyone on the team, especially more junior devs. It gives everyone on the team a sense of ownership in the team's projects. And the more senior devs can spot and prevent issues in the early stages before we've spent a lot of time going down the wrong path.
This has worked amazingly well for my team.
posted by Jeffry Houser in
Software Development, Professional
| 0 Comments
