1

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.

4
  • "I'm currently organizing a software project via Jira on my own" - that is not understandable!
    – jonrsharpe
    Commented Nov 30, 2020 at 13:05
  • What do you do not understand? I can try to formulate the sentence differently: "At the moment I am organizing a project on my own and I use Jira for it". Commented Nov 30, 2020 at 13:13
  • Sorry, it wasn't a language problem exactly, more that the behaviour of using Jira to organise a software project (especially when you're the only person on it) doesn't seem rational.
    – jonrsharpe
    Commented Nov 30, 2020 at 13:16
  • Sidenote - consider checking out pm.stackexchange.com - there's a dedicated stack for project management.
    – Sarov
    Commented Nov 30, 2020 at 19:57

3 Answers 3

3

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

enter image description here

1

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.

0

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.

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.