Every ticket in the developer board should be able to be traced back to it's source. Briefs and Feature specs are the prep work that is required to get stories or tickets ready to go into the dev backlog. Treat briefs and features specs as a wiki that gives context to the tickets that are in progress.
A technical backlog is a place where your team can either thrive, share knowledge and instantly understand what work is the most important. Or it can obfuscate reality and create conflict within the team.
Random ticket test
Anyone should be able to grab any ticket from the Developer Board and within about 2 minutes be able figure out:
What initiative is this ticket a part of?
What are the outcomes of this initiative?
How does this ticket fit within the wider strategy of the product?
Make work visible
Use visual boards and tickets to represent work to share status with any interested party. Tickets are a unit of work they can be a task, gherkin spec, user story, integration, UI fix, or any piece of work that the team does. The point of a ticket is that they are visible, trackable, relationship-based, trackable, and share context. You can see who is working on what and updates on their work.
A well-designed developer board allows any team member to look at the board and understand the status of all work on the go. It helps build trust within the team through accountability. Visualised boards can also be set up to chow remaining work and communicate timelines without estimations.
Who owns the work: Tech Lead
Who's involved: Software developers, Product Manager
The product manager defines the 'What', and the Developer Lead defines the 'How'. When a Feature Spec is ready enough for the dev team to start building it, that feature spec is prioritised against all other Feature Spec by the product manager. However, as that Feature Spec gets scoped into the backlog, the Developer Lead is responsible for managing how that feature will be built.
They can choose to map each ticket to a spec, a user story or add additional tasks such as reducing technical debt. The Tech Lead works with the dev team to manage who is working on what ticket and when.
Scoping and triaging
Who owns the work: Tech Lead
Who's involved: Software developers, UI Designer
The transition from feature spec into a developer backlog requires a lot of thinking about the future and predicting work. The Developer Lead needs to map out the work required to deliver the feature, which is more than what is usually held in the requirements documented in the Feature Spec.
This may involve Spiking out unknown or complicated tasks. Spiking a task is where you set a time box and give yourself a hard deadline. The goal is to uncover complexity by starting the work and provide clarity to the team about the remaining tasks to delivery the work.
A tech lead is responsible for working with the team to figure out how to best accomplish the decided solution that the tech team is building. They think about technology choices, work with other devs to up-skill them, and make sure that their tickets are in order.
Limit work in progress
We can either do many things poorly or one thing well. There are times to take a generalist approach and times to take a detailed oriented approach. Software development is a time for detail. Kanban methodology suggests that one of the best ways to drive progress in a team is to limit work in progress.
Meaning that teams don't work simultaneous on too many features at the same time. If you limit work in progress, you end up finish one feature and can release the value sooner that if your split the time across multiple features.
Reducing bugs in production
Who owns the work: Software Developers
Who's involved: Product Manager, Customer Support, Tech Lead
One of the biggest time-sucks that creates stress and pressure for the team and has the possibility of costing the company huge amounts of money in operational costs, future business, reputation, legal fees, and opportunity is a bug in production.
Bugs in production, or software defects, come from code that doesn't work as expected to make it into the hands of your users. Some bugs, may just be cosmetic - with no real damage done. But, the cost of a bug could make or break your product.
A bug or defect could:
create a data breach,
incorrectly manage money or billing,
prevent access or use of your product, or
cause reputation damage.
Fixing a bug takes resources away from other features or parts of the business. Non-critical bugs are twice as expensive to fix after release and critical bugs are 100 times more expensive to fix after release.
Many people have researched this topic for a long time. The challenge is getting recent data on the issue. From a paper published in 2002:
About 40-50% of effort spent on avoidable rework.
About 80% of the avoidable rework comes from 20% of the defects.
Peer reviews catch 60% of the defects.
Disciplined personal practices can reduce defect introduction rates by up to 75%.
For product development, a developers effort should not be focused on building new features. Instead, their effort should be focused on reducing bugs in production and tech debt while building new features. Dev teams can accomplish this by combining several of the practices together to increase their chances of removing bugs in production.
Code check out
Beta testing with more that 1000 users
QA testing - with less than 10 users
Modeling and prototyping
Each one of these techniques has on average a 45% success rate for preventing bugs in production. The best way to reduce bugs is with Pair Programming or Extreme Programming. With Pair Programming, you combine a code check out, code review, design review, code inspection, and other techniques which are shown to make the largest impact on reducing bugs. If you combine pair programming with automated tests then you can increase your likelihood of reducing bugs by up to 95%.