The backlog should only contain changes and additions to the product.
If it can’t be shipped, it doesn’t belong in the product backlog.
Your backlog is not a time-tracking system
Your backlog is not a time-tracking system; management and HR should not be using it to performance manage individual team members.
Your backlog should not contain tickets for supporting activities either. Whilst much analysis, planning, documentation, product communications and other supporting tasks will be required along the way, none of this should be explicitly captured as first-class tickets in your product backlog.
My opinion on this is unusually strong and uncompromising, and also unpalatable to many. However, it is formed through many years of seeing what works best in well-performing agile/Scrum development teams.
The backlog should only contain changes and additions to the product.
Unfortunately in 9 out of 10 times, non-product work appears in the backlog, often for people tracking and management visibility.
However, let me offer you a few alternatives in the remainder of this article.
How can I track the performance of the team?
Simply by using the product backlog, as it is intended.
The goal of an agile development team is to marshal through the most valuable backlog items in the most efficient manner. That’s it. The team can have other goals too, but they are secondary to performing as an agile development team.
The backlog is used to note down, consider, assess, prioritise, plan, schedule, and track changes and additions to the product, as they make their way through the entire SDLC from nascent idea to deployable code.
Examine the throughput of completed product backlog items over a fixed time period. Then make carefully selected and planned, whole team interventions as required. Review the impact of these over the next fixed time period.
This will clearly tell you how your team is performing.
How can I track what the business analyst is doing?
Whether you have enough fully refined stories to bring into the next sprint is the ultimate measure of how the business analysis is going.
The output of refinement sessions should be a good early indicator of this.
Refine newly drafted stories with the development team often, ideally throughout the week. Any outstanding analysis required on a ticket-by-ticket basis will quickly become clear, and tickets will remain parked until done so.
Ensure you have some way to mark fully refined stories, so they can be identified later.
Measure frequently the number of stories that have been refined with the team and deemed ‘Ready to Play’ (nb. you will need to consider prioritisation and dependencies between stories as well, but we are down in the weeds now).
You will know the business analyst is doing well if there are always enough stories ready to bring into the next sprint.
How can I track what the tester is doing?
Assign the ticket for the work being tested, to the tester.
And ask them for an update during the daily standup.
Consider changing your ticket workflow to include an “In testing” state if that is really important to you. Visualise this additional state on your Scrum board (usually a status column). Now it’s clear what is, and isn’t, currently being tested.
Whatever you decide, avoid creating separate testing tickets to sits alongside the original product backlog item.
Remember. If it can’t be shipped, it doesn’t belong in the product backlog.
How can I manage individual team members?
I’m assuming you mean beyond just the daily standup…
Speak to them. Understand their strengths, weaknesses, hopes and fears.
Work out what needs to happen on the job.
Then collaboratively develop an employee training plan and/or performance management plan.
Review jointly. Like you were doing before agile came along (you did this, right?)
Trust your team and enjoy being agile
Ensure your Scrum board accurately represents the product work your development team is currently doing or planning to do.
But beyond that, avoid the temptation to have every team member, account for their 8 hours per day, through tickets sat on the board.
Not everyone works like that, not every role works like that.
Trust your team to do the right thing and encourage them to speak up if they are not best utilised.
Choose to deliberately set aside the anxiety of not always having a fully loaded Scrum board, and really start to enjoy being an agile team.
If you are unhappy with your development team, they may need more detailed guidance.
Better software requirements can help with this.
|
Frank Ray Consulting. Software requirements for agile development teams, particularly remote, outsourced and offshore development teams working in financial services. |