Jellyfish announced the launch of Jellyfish Benchmarks, a way to add context around engineering metrics and performance by introducing a method for comparison.
Many software development teams struggle with an overwhelming and seemingly never-ending influx of new requests. Different business groups such as sales, account management and customer care will often demand new features or product changes, particularly in large enterprise organizations.
They’re all fighting to do the best job for their clients but without proper prioritization, every request is viewed as a high priority. This can lead to frustration as development teams are overloaded and stuck working to put out fires. It’s also extremely inefficient to constantly change priorities.
It’s important to have a clear product roadmap with solid release planning in place. A time box release cycle can introduce some stability and predictability for IT team, business team, and clients. It can be challenging to present a time box release model to a waterfall development team, but the benefits will soon become clear.
1. Time box releases
The idea that “it will be done when it’s done” doesn’t really suit anyone. Business groups are frustrated because they cannot communicate a reliable release date to their clients. The clients are not happy when product release dates keep slipping. A simple solution is to time box the release cycle and fix the release dates. It may take some tweaking to find the right fit, but start with a cycle of between four and eight weeks. Now you can calculate the capacity of your available resources and figure out how much work can be completed within one cycle.
It might be a good idea to start at six weeks and plan to reduce to four weeks after a few cycles, as people grow familiar and get comfortable with the new process. Different cycle lengths will suit different companies; the goal is to have a fixed date for each release which is reliable and predictable to communicate in advance across functional groups and external clients.
2. Prioritize requests
Ask each business group to submit a list of their top 20 requests and rank them according to how important they are to the client. Sit everyone down together for backlog grooming where scrum master, product owner, developers, and QA work in concert to understand the request, estimate, and then to slot each item from the top down into the release backlog that everyone commits to for production delivery.
Bear in mind that this needs to be staggered. If the release cycle is four weeks, for example, the product owner needs to set a deadline one or two weeks before the cycle starts to ensure requests are submitted and the team has time to sort them into the release backlog.
3. Lock it down
It must be crystal clear to each business group that if they decide they want changes to requests that have been made, or if they want to request something new after the deadline, they’ll have to wait for the next cycle. Once a cycle has been started, the backlog must be locked down. Preventing changes to the backlog that interrupt the priorities being dealt with without prior or adequate justification is vital. This is the only way to guarantee that everyone’s top priorities will be delivered in the next release. Business groups must understand this logic, and should explain it to their clients.
4. Always have a contingency
It’s pragmatic and sensible to leave a contingency reserve of around 10% to 15% of total team capacity. If someone tries to push a request through and isn’t willing to wait for the next cycle, then push back and make it clear that it will only be considered if it’s genuinely urgent. There will be emergencies from time-to-time, or client demands that simply can’t be ignored. In these cases, the executive team must approve before the new request can be assimilated into the current cycle.
5. Plan ahead
After a few cycles, you should find that business groups appreciate their priorities being delivered on time, clients are enjoying a better product, and urgent requests decrease. It’s now possible to plan further ahead. Sit down with the product owner and look at the next six months or a year. Fix release dates and set deadlines for project submissions accordingly so that everyone has a clear roadmap and a realistic timescale for project planning. This stability helps you to eradicate the fire-fighting mode and get everyone focused on improving the product.
These tips should give you an idea of how to go about prioritizing release backlog, but you should remember to start with small changes and revise your processes frequently until you get to a point that work for most, if not all. Finding the right cycle length and establishing stability can be challenging, but the potential efficiency gains, impact on product quality and client satisfaction make it well worth persisting.
Tram Tran is Senior Engineering Manager at KMS Technology.