1

Our software department consists of a single-product team of three developers and two higher-ups with domain knowledge whose roles on our team are similar to that of a product owner.

We have organized our backlog into a single Trello board with four columns: Unreviewed, Wishlist, Future, and Soon. New items that come in through our help desk are added to Unreviewed so they can be reviewed, estimated, and sorted into one of the other three columns during our weekly meeting. When we create a new sprint, we populate it with items from the Soon column based on priority and scope of work.

Currently, we've been creating a new board for each new sprint, with the board being named something like "Sprint 6/6/19 – 6/12/19". This makes it easy to see just what's in the sprint and see what everyone's working on, but it also makes it hard to do reporting from a central place. There's also a tendency for long-lived items that take weeks to get through to keep getting kicked to the next sprint once that sprint is complete.

Are these just innate characteristics of multi-board projects, or is there a better way to organize things?

Improve this question
5
  • 1
    One project, one board. While you can do funky and weird things with multiple boards, the juice is rarely worth the squeeze.
    – Todd A. Jacobs ♦
    Commented Jun 12, 2019 at 21:40
  • If you really need a multi-board workflow with unified views, consider Favro rather than Trello. YMMV.
    – Todd A. Jacobs ♦
    Commented Jun 12, 2019 at 21:41
  • @ToddA.Jacobs Do you know of any Trello power-ups that make working with sprints within a single board viable? If such a thing exists, then one board definitely seems like the way to go
    – Jacob Stamm
    Commented Jun 12, 2019 at 22:48
  • Are you trying to practice Scrum? Are you trying to get a particular benefit out of "sprints" if not?
    – Daniel
    Commented Jun 13, 2019 at 15:57
  • @Daniel The benefits we want are better organization of our backlog and regular, frequent releases which pull the most important items from that backlog.
    – Jacob Stamm
    Commented Jun 14, 2019 at 14:15

1 Answer 1

Reset to default
1

It sounds like the underlying challenge you are facing is a lot of items spilling over sprint-to-sprint. Otherwise, you could have one board, pull from the product backlog into a sprint backlog, work those items to done, then pull the next set in the following sprint.

A key part of using sprints is that the timebox provides a constraint. Among other values, that constraint pressures the team to return to a stable, releasable state every iteration. The frustration you are experiencing is because the constraint is highlighting the difficulty the team is having wrapping up the sprint. So, if that is still a valuable tool, you should not make adjustments in the board to relieve that pressure, you should work to make sprints completable. (including including addressing the root cause of long-lived backlog items)

Improve this answer
1
  • Good answer! This is where the backlog comes in handy; anything that's spilling over from sprint to sprint should actually be in the backlog. It's better to complete a few things than to leave a lot of things undone within a sprint.
    – user27307
    Commented Jun 14, 2019 at 20:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.