> 3. Don't need a JIRA task for everything
Genuinely asking: how so? Tickets are not just some bit of bureaucracy, they are also a living log of what has been done and why that thing was done.
Genuinely asking: how so? Tickets are not just some bit of bureaucracy, they are also a living log of what has been done and why that thing was done.
If you try for an hour and it's still not done -- make a ticket.
There's nothing more annoying than seeing the same trivial task get shuffled around 4 sprint planning meetings, taking mental overhead from 8 people.
And nothing comes out of sprint planning with less than a quarter day allocated. You've turned a 20-minute task into a whole day of wasted effort.
Sure, but that doesn't mean you can't create a ticket for it. It just means that you have tickets which fall outside your sprint planning flow.
There's no need for a ticket for small tasks, unless you are being evaluated on number of tickets closed (which is a separate problem)
You can create tickets for every small thing, but it might not be very efficient.
The devs on my team are encouraged to move tickets around and plan their time however they want, but JIRA allows our product, design, dev, and qa teams to coordinate without being in the same room every day. It's just another form of async communication that helps us make sure we're shipping everything we promised, and fixing all critical bugs before the end of the week.
For us tickets are most important to track what gets included in releases and patches, and to tell QA to test our branches (and we almost always require QA to test our branches before they're merged).
Huh... you've never had 10 things that are worth doing that take less than an hour? Or did you just line them up and work 10 hours that day?
You need some way to prioritize and work against those priorities, typically measuring impact or some variation of ROI.
And as bonus points it can effectively prevent people from gobbling up only the work they want to do and leaving the shit for everyone else.