How to deal with story-cards on a simple issue-board in Jira

Question

I'm currently organizing a software project via Jira on my own. Right now I'm the only one who is developing on that project. However it is possible that more people will join the team in the near feature.

I'm now wondering how to deal with stories and tasks. I/we don't using Scrum but a Kanban board with three columns (backlog, in progress, done). There are a lot of epics and tasks to do and I just included a new issue Type named "story". How would you handle the state of the stories?

For example: There is a story called "As a user I want to print the document" and a couple of tasks which are related to that story like "add printing button to UI" for example. When starting a task, I will move the card to the "in progress" column. The Question now: Should I move the story on the board to "in progress" too? Should we display stories on the board in general? It's feeling a bit like doing redundant organization since I/we have to check the stories every time tasks changed "by hand" (checking "are all related tasks done?" If yes then we have to move the story too). Or should I avoid using the concept of stories in general?

I hope it's understandable what I'm trying to describe.

Answer 1

Don't have a separate card for the story. Mark all the cards in the same story with a sticker/colour or swim-lane

Answer 2

Having a separate issue type makes sense. This allows you to set up different Jira workflows with states for different issue types easily. Having issue types for Epic, Story, Task, and Bug makes sense. However, when you put them onto a board, there doesn't necessarily need to be a 1:1 mapping between workflow states and board columns. Perhaps, for now, a backlog (or a backlog column), a "to do" or "ready to work on" column, an "in progress" column, and a "done" column may be sufficient. Depending on the workflow associated with each issue type, there could be multiple states inside of each column.

A Story issue may be a good example. The "in progress" column on the board could represent multiple states - coding, testing, waiting to be merged. If you are working alone, this could be fine. However, if you are working with a team, it may be more important to visualize when something is waiting for a code review, so a workflow state associated with work ready for or undergoing a code review may be split out into a different column than working being developed or tested by a developer.

As far as tasks go, I would consider a parent to be started once any subtask is started. I would also consider a parent to be done when all subtasks are done. You can use Jira automation to help this along, as well, and avoid the game of moving tickets around. If you aren't using subtasks, I'd recommend either using subtasks or just encapsulating all of the work in a single ticket to avoid ticket management hell. Most teams that I work with tend to use subtasks sparingly, unless multiple people will be working on a parent ticket because of the overhead of creating and managing parent and child tickets.

Answer 3

How would you handle the state of the stories?

How we would handle it isn't relevant, as the answer is going to depend on your situation. So, rather than a concrete answer, I'm going to tell you how to arrive at one yourself/yourselves. All you need to do is "Do the simplest thing that could possibly work". And to do that, just follow these simple steps:

1. Define your process as simply as possible. Err on the side of simplicity.
2. Try it out.
3. In a Retrospective (I'm aware you're not doing Scrum, but the Retrospective is a good part of Scrum to steal), check whether it worked
   • If yes, you're done!
   • If no, refine your process and return to step 2

Should I move the story on the board to "in progress" too? [...] stories in general?

What I think is tripping you up here is something that tripped me up when I first started using Jira.

Don't split a Story into Tasks. Split a Story into Subtasks under that Story. If you do that, Jira will suddenly understand that they're related/hierarchical, so it will automatically ask if you want to put the Story to Done when you move the last Subtask to Done.