Hey ! Just writting a quick post to avoid you being surprised if things are changing a bit in ZenHub, Discourse, etc. We are working with @danielle@Kirsten and @Rachel on process improvement, with a “try and learn” iterative spirit to refine and fine a way to handle priorization and curation in a smooth and open way.
What do we put in the dev pipeline is taken from 4 “pots”:
sys admin backlog
bugs packlog
tech debt backlog
new features backlog
For the first 3 ones it is handled usually directly on GH so I just created three columns where we can add the issues we want to enter the backlog (first level of filtering, for example we put only s3 bugs) and within it, we order by level of priority/emergency. So we know that we will take the top issues of those 4 columns to fill in the backlog.
We are not clear yet on how to do the priorization in each column, but suggestion could be:
tech debt devs decide together with agility and consent base on tech debt and sys admin, like one suggest an order, other review and when new things come up, put it somewhere in the priority list and other will review and suggest something else if they disagree.
product owners decide together with agility and consent base on bugs (same process)
We are still working on new feature process, the idea we are exploring is to have some voting on wishlist on “what needs to be investigated/incepted first”, inception details feature candidate and enable choose one, those feature candidates enter the new features backlog and we prioritize there, either by voting, or same way we would do for bugs and tech debt (we might not have dozens of incepted feature candidates at the same time, inception takes crazy time!). We’ll come up soon with some more refine proposal, was just sharing that so that you are not surprised to see things moving a bit in GH and Discourse
I was thinking as a side note, what if we setit up so that each developer dedicated n% of their time each week to tech debt and bugs? That way there is always at least a small amount of focus on these, and part of that time is for them to coordinate the tech debt backlog and to select the next thing they will take on?
S1 and 2 bugs obviously would continue to be the most important things of all, but but allowing some time specifically to focus on these other things we’re making what we have great and future proofing the tech platform, both things we agreed were key areas of focus for this year.
Sounds good. Sometimes I find it difficult to find out how much time I have left on a task though. And then I need to stop one thing to do another thing, go back later again and it’s not very efficient. Maybe we can define a ratio. For example after each fixed bug, we work on one tech-debt issue. Or we say that we do one per week, per fortnight or whatever. That would make it much easier to do one task at a time and actually finish it instead of doing many things over weeks.
I agree with @maikel that it’s better with good focus on the current task.
What if each core dev has a ratio with 3 weeks working on features/epics and the following 1 week they work on bugs (s3 and below), tweaks, tech and sysadmin?
s1/s2 bugs being prioritized whatsoever.
The ratio above is just an example of course and it should be somewhat flexible and open for iterative adjustment.
I like @sigmundpetersen suggestion. In my mind this is the closest we can get to a scrum sprint, in which it would be easy to book some time for these things (at least in my head).
or certain devs are on a new feature while others are on bugs and tech debts and sys admin, and then we turn role to ensure diversity of work for devs and avoid monotony. So bugs get solved regularly instead : all devs work only on bugs for 1 week every 3 weeks and other things stop.
or does all dev do every week 1 bug from the backlog that have to integrate how they want in their pipe?
or…
I would like some more precise feedback from devs on how concretely you would like, personnaly to manage feature, tech debt, bugs and sys admin. If you are in a feature, do you prefer to stay only in this feature? Or disctract yourself with some light bugs ? Same for tech debt, etc.
i like when there is one single todo list for the totality of the project. features and bugs sorted in one list always uptodate.
them devs have one right: inject some tech debt items on that list.
and then no rules about what/when to do things except one: dont be away from the top of the backlog for too long.
so. i am doing the spree upgrade but i could change my mind tomorrow and start fixing all the anoying s3 bugs or help Kristina kill the fees report or subscriptions. i think devs doing what they want at anytime (as long as its linked to the top of the backlog) is a really powerfull thing.
this is my personal preference.
Interesting ! I Like this idea… so I guess the idea would be that the curation team would take “items” from the bugs and feature and sys admin backlog and order them TOGETHER in a “dev ready” backlog where devs would pick the top things? And can inject some tech debt as you suggest ? It doesn’t prevent to have some “tech owner” on feature that have some “leadership and responsability” to make it move forward. But I like your approach @luisramos0
I like that as well. It gives us freedom to decide in the moment, but we also have a priority list to work with to make sure that the important things get done quicker.
Hi everyone ! After the delivery train catchup this morning I said I would sum up the discussion and new adjustments we did on ZenHub.
Now there are:
4 backlogs column where we put bugs / sys admin / tech debt / features that are ready to be put in the pipe (dev ready)
1 dev ready column where we put the high level epics for feature and some tech debt (like spree), and stories for bugs, tech debt, sys admin. The idea is to enable better visibility and understanding of the whole team of what are the priorities, and enable to include bugs and tech issues in between epics so we get them done as well.
Given discussion on limiting WIP is seems the plan is to limit to
3 epics (including tech epics like spree upgrade or api work)
5 bugs
5 tech issues (tech debt and sys admin)
Then 1 column per epic where we can prioritize stories. So if a dev jump on epic n°2 (because epic 1 is almost done and would take too much time to dive into it), she can then expand the column for this epic and take the top issue.
That’s a summary of it, and we propose to test and see if that feels better for everyone !
