Optimal Issue Length

[miniscruff]

First off I love this, short, simple, easy to follow.

As a long time developer, I just want to suggest a small change.

An Issue is any unit of work that should take 4-8 hours of engineering effort. An Issue is either in the current sprint or in the backlog.

The previous bullet point mentions reducing context switching. If a developer does an issue every 4-8 hours over the course of 15 work days ( 3 weeks ). That is roughly 20 issues in the ideal sprint.

My suggestion is similar to what basecamp has published as how they work here: https://m.signalvnoise.com/how-we-structure-our-work-and-teams-at-basecamp/

Rather than filling the sprint in 4-8 hour tasks I would propose organizing issues as fully complete "deliverable" features. That is instead of breaking down the login system into small tasks. I would recommend simply making one issue that encompasses the whole system. If it takes more than 3 weeks it can be broken up. However, I would keep from breaking issues too small.

This way each developer can focus on 1 or maybe 2 issues a sprint.

I would also like to add that the end of the issue should be that it is released into production for all users. Currently, on my team, we have the issue where the work may be done, but deployments are still on hold which causes lots more issues and requires we contain that context for sometimes weeks.

So my rough draft change could be something like...

An Issue is any unit of work that is delivered to all users that can be completed within the sprint. An Issue is either in the current sprint or in the backlog.

Note that this would be changed in both the developer and manager pages it was referenced in.

Let me know if you have any questions or comments. Thank you.

[davebs]

Yeah, those are good points.

I haven't read that blog post from 37signals but am a big fan of the company and many of their philosophies wrt organizing a business/project. Let me take a look. My current wording is awkward and could use a revision--I think yours is probably fine. Will leave it up here for a bit in case someone else wants to weigh in.

On the point of deployment/delivery at the end of an issue, my instinct is to be agnostic as to method. While there are many good arguments for continuous integration, I find there are reasons in practice for waiting on deployments and those reasons can vary a lot depending on the company/team/project. In these cases, I think it could make sense for "deploy to staging" or whatever to be an actual Issue in the sprint.

[miniscruff]

I see your point on being agnostic on continuous integration, and how it ( probably ) extends to other tools and processes like test-driven development, pair programming, etc. There are always going to be companies or projects that may follow some but not all and that's totally fine. Delivering to users as a requirement would also go against workflows such as gitlabs release cadence and other timely releases.

Maybe one of these alternatives.

• An issue is any unit of work that can be completed in its entirety within the sprint. ( this assumes there is some understanding of entirety for the team/project/company but that we are agnostic on what that is. )
• An issue is any unit of work that can be completed based on your team/project/company standards.
• An issue is any unit of work that can be completed within the sprint. ( just no extra statement about requirements )
• An issue is any unit of work that can be completed in a single sprint, splitting if necessary. ( Can also include a small detail that favoring larger issues is ideal. )

I would still include the second sentence of being in the sprint or backlog, I think that is very important.

I think the difference here is all very minimal so whatever aligns more with your vision.