If someone is looking for additional work, they’re welcome to pick up the following tickets:
(list tickets or insert link to appropriate filter)
This is tricky for when you want to look for tickets though, because you need to open all the epic tickets and check the latest epic updates for each.
Instead, what if epic owners simply put these tickets in stretch goals?
I think the definition of stretch goals lines up with tickets from an epic that are ready to be picked up by anyone.
This could be easier for epic owners, as they can simply drop some any ready tickets in stretch goals when checking tickets. And this would be much easier for members looking for tasks because they can just check stretch goals for unassigned tickets.
In concrete terms, the changes would be:
the section above dropped from the epic update template
update the description of the listaflow item “Ensure the necessary tickets are created for each of your epics.” to include moving any ready but unscheduled tickets to stretch goals.
update the work finding checklist to include an item near the top for “check stretch goals for unassigned tickets”
That’s a good idea! Isn’t backlog the same thing? What will be the advantage of moving the tickets to stretch goals vs keeping them in the backlog? I was thinking on the lines if we could devise a filter where we can get the tickets that need an assignee and are ready to be worked on, maybe through a label. I am just thinking out loud here
This sounds like a great idea! @farhaan I think keeping them in the backlog will mix them in with many tickets that can’t or shouldn’t be worked on, so Stretch Goals is the best place for this.
I have a specific case - What if the tickets are scheduled for future sprints based on the budget run-rate or capacity allocation and also included in the additional work bucket? Isn’t that how “project” epics work?
If a ticket is in the backlog, they are usually blocked, if they are available for work, they will be in a sprint. I find the need for stretch goals redundant.
I see Stretch Goals as a way to indicate that a ticket can be worked on in the current sprint without actually injecting it or requiring budget confirmation. Sometimes it can be replaced by scheduling these tickets for a future sprint, where they can be pulled, but it reduces their visibility and adds friction to taking them.
I actively avoid using Stretch Goals. It acts as a procedural trap for me, since any ticket in stretch goals will stay in stretch goals forever until manually removed, which means that if I don’t remember to switch a ticket’s sprint from stretch goals to the next sprint, that ticket which was ready and planned to be done, just not yet suddenly is back another couple of weeks when it could have been taken in the next sprint.
After this happened a couple of times I swore off of it and always just put the ticket in the next sprint.
The backlog is the default ticket state, and generally tickets here are not ready to be worked on - they’re blocked on budget, not specced out, scheduled for a long time in the future, still under discussion, blocked, etc. etc.
There is some middle ground though: available for work, but no-one was able to commit to them in a sprint. In the sprint planning back when we did synchronous planning meetings, any tickets in the sprint that we couldn’t find an assignee and reviewer for were dropped out to stretch goals.
We could simply push them back to future sprints, but often tickets in future sprints aren’t ready to be worked ahead on - as you mentioned they may be in a future sprint to spread out the budget usage for example.
Yeah this is the major problem with stretch goals. I think we can solve this with a manual or automated step to push everything from stretch goals into the upcoming sprint on the second wednesday of each sprint. But maybe that will have other issues?
Or as some of you have suggested, we just drop stretch goals and always put tickets ready to work on in the upcoming sprint. We might need a way to mark tickets as “not ready to work ahead on”, but otherwise could be fine?
An automation would be preferred here. Technically, manual step(s) already exist-- in the epic update, asking you to attest that every ticket is in the right sprint/status. But those are usually done on the first Wednesday of the sprint, which makes it not especially helpful for the case of stretch goals, only for those tickets assigned to specific sprints.
As for downsides, the second Wednesday (or after) might be about when someone starts running out of tickets, and starts looking for more work. Then they’d have to go into the next sprint anyway. it would be preferable if there were one place to look for new work.
What if, instead, we changed the ‘tickets you can pick up’ field on an epic update to be formatted as crafty directive to be filled out by each team member, and then Crafty can collect these and post the up to date ‘available for pickings’ tickets somewhere?
Everyone has to do the updates, they’re gathering a list of ‘ready to be picked up’ items, so just putting a couple of tags around them should make this easy. Maybe we have another thread where Crafty posts these tickets, or maybe it sticks a label on them (in this case, you could argue that we should just tag those tickets manually, but this way it makes it easy to verify that someone’s done it when it’s in the epic update.)
