What's the best way to have the fucntional design in Jira?

[DPereira]

Hello everyone.

So my problem is; what's the best organization of a Jira project in order to easily be possible to have Functional Specification, Design, Frontend, Integration (.net, Umbraco, etc...) and testing tasks? 

I already saw a lot of videos with dummy examples, but what I need is a real live example.

So for example: i create a story do define a user login. But then, there will should be a task for a designer draw the screen, then another for the HTML, then another for let's say Umbraco. Should I create 4 stories called "Login screen - Functional specification", "Login screen - Design", "Login screen - HTML", "Login screen - Umbraco"? Or these should be subtasks of one story with the functional specification? I tried this but then the problem is that the story doesn't last 1 sprint because the design is done in Sprint 1, but the implementation in Unbraco in 2 or 3 and the sprints start to accumulate a lot of stories and it's not manageable. 

Even if i create several boards for each different type of role, how will that solve me the problem of having the functional design accessible in Jira? I would really like to avoid external word files and i don't want to have Confluence.

Any practical example, screenshot will be very useful.

Many thanks

[Mykenna Cepek]

So in your question, I hear that you are using Jira to support team development using Sprints (aka Scrum), and that you want to break down your work using the hierarchy of Jira issues (e.g. a Story with multiple Subtasks).

I also read that your Stories (for some work like developing a "Login Screen") tend to last longer than a Sprint.

My first thought is that Scrum might not be the best fit for your team. When a team uses Scrum, an assumption is that the team will work together to complete as many Stories as possible during the Sprint. This can work great for teams with cross-functional team members, but it works less well for teams of specialists (front-end, back-end, DB, etc).

Another possibility is that your Stories are too big. Again, a Story should be something that can be completed in a Sprint. I coach teams towards the average Story going from start to finished in 2-4 days. That allows a team to complete quite a few Stories per Sprint, with only a few rolling over.

A different approach would be to use Kanban (instead of Scrum), so that the length of the Sprint doesn't feel like a limitation. You'll still have issues with the team having "lots of stories In-Progress at once". But if you've got a team of specialists, that might help you focus more on the work and less on fussing with the overhead of Sprints.

Finally, consider using all of the Jira issue hierarchy. If you're not using Epics, those might help you break down and/or organize the work differently. For example, perhaps you would use an Epic for "Login Screen", and then the various Stories for "Design", "HTML" etc could go into different role-oriented projects (a team of Designers, a team of web coders, etc).

Subtasks could then be used within the team for finer work breakdown. For a "Design" Story, you might have Subtasks for "Mock-up", "Mock approval", "Design", and "UI/UX review" (just making up some examples). 

Most agilists (like me) find that sort of "silo team" approach to be anti-agile. But it sounds like you're just trying to use Jira with the work and the teams that you have. So that might be an approach that works for you. If "being more agile" isn't that important, just organizing the work effectively in Jira might help you and your teams be more productive.

Don't be afraid to experiment. Try something, and see if it helps. Iterate. Inspect and adapt. An advantage of Jira is there are a lot of different ways to use it.