Assuming Kanban (as I think the answer is less relevant for a Scrum process), the lanes that you should use depend on organizational concerns, and perhaps on your definition of done. You’ll probably start to see an obvious need for things as you start working through organizational or business concerns beyond just development concerns.

In my current organization, “Ready for Acceptance”, “Ready for Release” (aka Accepted), and “Released”, are in there, because we consider Product Owner acceptance of a story an important gate, and it’s not always an instant thing depending on the PO’s other obligations with the business. We don’t yet have a continuous deployment mechanism in place, so we also still have a lane for things that need to be part of a release event, and there may be some work on our part associated with that. Then we have “Released”, mostly for the benefit of recognizing progress.

In another organization, Kanban wasn’t our primary process but we needed to deal with a lot of moving parts working through multiple organizational gates, as we were serving a highly regulated biotech business. Some items were “In progress,” meaning in the developer’s hands, but needed to be pass through a “tech writer review”, a “test” effort by a traditional software test team, and Quality Assurance. (The distinction was a matter of industry standards; in traditional manufacturing, QA assures that processes work as documented, whereas “test” is a matter of quality control; our software had to go through a QA process because we got FDA approval on the condition that we followed our documented Good Manufacturing Practices as originally documented to the FDA years ago). So, in other words, although the software organization practiced enabling mechanisms for agile development like continuous integration, automated unit and integration testing, and so on, various business constraints meant we had to juggle external organizational concerns that were more reminiscent of legacy-style project management. When our development team was trying to juggle multiple work products (new features, release of old features, dealing with organizational and technical problems that sometimes spanned multiple Scrum iterations), we essentially abandoned Scrum so that we could provide visibility into what we were doing that wasn’t development, and make sure everything got done. When our work was less dependent on external interests, we used more traditional Scrum-style project management again.

If I were in a small team and had few external stakeholders, I’d probably keep my board pretty simple. “Ready to pull”, “In progress”, “Released to Production” would feel just about right, but it wouldn’t surprise me if the product owner needed some a lane to review the work before releasing to production. And in some organizations, where a new feature isn’t available to everyone until some data has been gathered on how customers react to it or how it scales in production, it wouldn’t surprise me to see a lane like “In A/B testing” or “Released to 10% of users” followed by “Released to all customers”.

We also have some non-shipping lane items like “technical debt”, and we sometimes recognize that a story contains inadequate acceptance criteria, contradicts other existing criteria for earlier features, or has some unforeseen consequences that require further discussion or review before cowboying up and writing possibly irrelevant code. In those cases, we have a box that, if things are working sanely, will be visited only briefly, labeled “On hold.”

So the lesson is simple: Figure out what your team actually needs, and draw those lanes.