How to prioritize a 90 issues backlog!
Don’t try it’s impossible and it should not be called a backlog (no it’s not a joke I’ve seen a 90 issue backlog). This drag&drop (or stick&unstick) improved spread
shitsheet may bias your brain making it thinking that you’re Agile. You’re not and you’re even an ankylotic grand’ma of project management not trendy at all. You don’t have a V model project you’ve worse : something unsuable, unprioritizable, stationary, obese. In IT/web related projects we love to boast about our usability but we don’t care about the usability of our backlog.
Grand’ma likes to make provisions but, no, please a backlog is not a shopping list for your project underground bunker, keeping tasks safe in case of a work scarcity, that’s not about to happen in IT these days (it reminds the pineapple can I found in my own grandma cupboard, 10 years expired about to blow-up).
A backlog, is less fun than that : it’s a contextual list of mature tasks, with a clear business goal, with clears expectations that are ready to be presented to your favorite development team.
So, how many stories should be in there ?
Well, it depends on your team “velocity”.
You should always have enough stories to keep your code-lovers busy. Enough stories to avoid you (as a product owner) a rush just before the sprint planning to write your specifications (and replace your “structure project management attempt” with “emergency low-quality user-stories writing procedure”).
But believe me, even in the previous project I managed, with 35 developers, with proxy-product owners managing their own backlog for their scope, its overall backlog had never reached 90 issues.
- We said no to “comfort” features or we had a seperate list of quick-win tasks. This keeps users in a high spirit, because there’s clearly a user bias that letting them thinking that quantity is more valuable that quality – when project are not moving forward quickly enough and they can’t understand why take a few hours of your sprint for quick-win session, your mind’ll feel relieved even though no real business value has been added (and in some cases mental health should be your first concern).
- We did regular clear-out : once the project is moving forward some feature that sounded important turn out to be out-of-date. Don’t be afraid to click on the « cancel » button of JIRA or even, if nothing scares you the « delete » feature hidden in the top-right menu.
- We continuously improved while assessing the team development capacity thanks to burn-down chart for instance to manage user expectations and help then prioritise their request knowing the time-limitation (of course they’ll always complain that the developers are lazy and do not code quickly enough).
A backlog should not required 1 day per week to be groomed. Whether you work with Kanban or Scrum methodology, at the beginning of every “sprint“ : review your business roadmap.
You have your milestones in mind ? Then ask yourself the following questions.
You’re working in startup where the word “planification” is a swear word : just do your best and try not to cry.
- Is it a must have for the coming weeks (days… in startup space-time).
- Is it a must have… for a use case that is unlikely to happen again (if you see a non-sense in the last sentence, you’ve never worked with stakeholders) : throw it away. Useful user-stories are like boomerang, they’ll come back if really needed.
- Is it mature enought = is it ready to be explained to developer and developped ? User-stories-for-later are “dust” on your grandma shelf.
If you’ve been gifted by your new project a multiple-of-ten stories backlog, maybe after a few weeks or a few months your Iceberg backlog will melt like a frozen canal in Amsterdam.
Huuummm that post sounds like common-sense… but I wonder why common-sense is not taught at school.
After three year as a V model project manager with unsatisfied stakeholders, frustrated developers, I had the chance to take part in a giant but human Agile project, from scratch to its maintenance mode prep, at different positions (analyst then Product owner then project manager). I’ve seen many methodologies been tested and, twisted, people happy to test and even to fail – where the sentence “we’ll lose time” had been replaced by “we’ll improve” I’ve worked with inspiring Agile coaches, eager-to-try colleagues that made me passionate about liberated organisations and Agile methodologies.
I’d love to evangelise co-workers with what could simply be called “common sense”.