Theory: User stories describe the Who What and Why something is needed from a user's perspective and act as a token for conversation within the project team. When they get estimated, they help the Business Owner / Product Owner / Recipient of the solution track progress of their project. Tasks, Improvements, Enhancements describe What's needed from the implementation team's perspective. Sub-Tasks can optionally define the How we are going to achieve the Task or Story and should be written by the implementers (developers, designers, builders etc...). My ascertainments: * When 1 task fulfils more than 1 story, we cannot use subtasks because there is 1 to many relationship (accepted). A story in that case requires more than 1 implementers with separate tasks assigned to them. Who is supposed to own the story and what's the recommended way to related those tasks? * Where stories are used to track progress of a project, you may have a lot of related tasks that will take 2 or more iterations to fulfil 2 or more stories. Where this happens it seems logical to promote the Stories into Epics but then 1 task can't be part of more than 1 Epic which is a problem. So the next logical action would be to associate them with a Theme - but Themes aren't a concept covered by JIRA Agile and the planning board. Is there a recommended setup? * In regards to QA - It's hard to find where this fits in into the process. There are multiple levels of QAing: Automated regression Testing, Code Review, UAT, Product Owner Sign-off etc...). We try using JIRA Capture but the ownership of an issue is then split and test session assignees can't treat a test session assigned to them as any other JIRA issue where they can track time, estimate, plan etc... neither is visible in any kind of reporting. This is not about workflow but rather about tracking tasks and ownership combined with Automation. So what is the recommended approach for enforcing and tracking the QA elements of a particular deliverable / story. My final observations and comments: JIRA and it's assortment of plugins are great for simple Task management - but for more complex projects and scenarios that involve cross functional teams there is a lot of uncertainty which can be helped by Atlassian trying to get more detailed case studies from their clients, or working groups, in various industries so that their customers can make the most effective usage of their rather "expensive" tools. It's great to see many plugins that help us do one thing or the other built by 3rd party companies but their products must not depend on them which is what sometimes you see over here coming up as an answer to a problem.

All in Jira so we can see the priority of the stories. Our product owner creates most of the stories. Developers create some. Together we update and refine them during backlog refinement meetings. If a very high level story appears at the bottom of the back log meaning it is still low priority, we will not bother trying to detail it until it is higher priority and closer to the time we plan to work it.

Dwight, Thanks for your extensive response. Just one last question - Do you write your stories directly in JIRA and refine the backlog there? Or do you use Confluence? Or paper cards? and then put them in JIRA once they are split and refined?

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Best practices using JIRA and JIRA Agile for cross functional teams

Angelos

Theory:

User stories describe the Who What and Why something is needed from a user's perspective and act as a token for conversation within the project team.
When they get estimated, they help the Business Owner / Product Owner / Recipient of the solution track progress of their project.

Tasks, Improvements, Enhancements describe What's needed from the implementation team's perspective.

Sub-Tasks can optionally define the How we are going to achieve the Task or Story and should be written by the implementers (developers, designers, builders etc...).

My ascertainments:

When 1 task fulfils more than 1 story, we cannot use subtasks because there is 1 to many relationship (accepted).
A story in that case requires more than 1 implementers with separate tasks assigned to them.
Who is supposed to own the story and what's the recommended way to related those tasks?
Where stories are used to track progress of a project, you may have a lot of related tasks that will take 2 or more iterations to fulfil 2 or more stories.
Where this happens it seems logical to promote the Stories into Epics but then 1 task can't be part of more than 1 Epic which is a problem.
So the next logical action would be to associate them with a Theme - but Themes aren't a concept covered by JIRA Agile and the planning board.
Is there a recommended setup?
In regards to QA - It's hard to find where this fits in into the process. There are multiple levels of QAing: Automated regression Testing, Code Review, UAT, Product Owner Sign-off etc...). We try using JIRA Capture but the ownership of an issue is then split and test session assignees can't treat a test session assigned to them as any other JIRA issue where they can track time, estimate, plan etc... neither is visible in any kind of reporting.
This is not about workflow but rather about tracking tasks and ownership combined with Automation.
So what is the recommended approach for enforcing and tracking the QA elements of a particular deliverable / story.

My final observations and comments:

JIRA and it's assortment of plugins are great for simple Task management - but for more complex projects and scenarios that involve cross functional teams there is a lot of uncertainty which can be helped by Atlassian trying to get more detailed case studies from their clients, or working groups, in various industries so that their customers can make the most effective usage of their rather "expensive" tools.

It's great to see many plugins that help us do one thing or the other built by 3rd party companies but their products must not depend on them which is what sometimes you see over here coming up as an answer to a problem.

Accepted answers

All comments

Ramiro P

Hi I'm going to describe how we are using:

1. The Epics are the major tasks in a project such as testing, development, analysis.

2. User stories indicate the who, what and why you described above. These are related to the epic.

3. Within the user stories we have subtasks. Basically we divide our user stories into smaller parts to be performed by developers. Each developer has their own subtask in which to work.

4. Regard to quality assurance we have a report type called Test Set that relates to the epic test. And, instead of having subtasks, we have test cases. Test cases can be linked to user stories as each user story can have many test cases performed.

I like customization, so each issue type has its own workflow and its own states.

Dwight McPeak

There seems to be quite a few ways to use JIRA depending on how your team works and what is most useful. Here is a quick overview of how we are using it and we have been quite happy with the results.

Epics are high level functional areas and tend to correspond to an application or web portlet for us. For example we have a "Registration" epic for registering new users to our web site.
Stories are created that relate to the Registration epic. They should be a potentially shippable chunk of work. It may not do all of registration but it does do a part completly. An example story might be "As a user I want to submit my profile information for registration including my name, address and phone number". Multiple stories would be created that all together would describe all the functionality of the epic.
Sub-tasks are created during planning with the developers and include all of the steps we need to do to complete the story. Complete meaning, it's ready to ship if we want to. Typical sub-tasks for us include code, code review 1, code review 2, update test cases, unit testing, test on development box, deploy to QA box, test on QA box, business user test. The generic "code" sub-task would only be used for small stories, it would be broken up into multiple coding tasks as needed for larger stories. We create "deploy to QA" sub-tasks as needed when code is ready to move to the QA box. Our QA tester on the team watches for these to know when to move the code to that environment for testing. If additional tasks are identified as we work the story they are added as needed for that story. We want any one sub-task to always be less than 1 days worth of work so we always see progress on our board for each developer each day.

Our board is very simple with the default three columns, Open, In Progress, Done. We move the sub-tasks through each status and we always know who is working what since they are assigned to the sub-tasks and we may have several people working on a story at any one time.

Angelos

Hi Dwight, Thanks for your response. I quite like the way you are using sub-tasks for QA but I still can't picture it working for me. I will try to put an example together so you can relate to my thinking and issues a bit easier: A client wants a content managed members only community website. This would be based in our existing community platform but will be tailored to the clients requirements by inheriting the base functionality and extending / overriding it. The solution implementation team consists of: Web Designers, Content Writers, Moderators, Developers, Server Administrators each of which will have one or more tasks to fulfil. =============== One of the Epics User registration and member's profile building Two of the Stories As a customer of that brand I want to register on the fred.com website So that I can join their community As the website owner I want to make the registration process and profiling usable and consistent with our brand So my customers that want to join the community can do it with ease and trust *Tasks and/or Sub-Tasks:* Design the registration page and form Design the email notification templates Get design sign-off Write the registration copy Write the T&Cs Write the email notification copy Write the welcome copy Get copy sign-off Setup domain and email accounts Develop the database structure that will hold the profile information Develop and Enhance the registration page of our existing standard community platform based on the signed-off designs Develop the registration confirmation functionality and email notifications Regression Testing Design implementation QA Code Review and Sign-off UAT Client Sign-off Deploy ================= 1. In the above two stories, there is a task for almost every member of the implementation team. 2. The tasks I listed would fulfil the needs of both stories so they can't be sub-tasks 3. The time that the tasks will take to be completed will be the length of 2 sprints or more 4. Assuming that we only estimate the stories there will be nothing to burn down against during the 1st sprint so it would seem we aren't progressing and we can't get an idea of the velocity 5. Due to the cross functional nature of the project, there can't be a single owner of each story 6. Tasks and/or Sub-tasks aren't meant to be Estimated with story points (I know I could configure JIRA so it allows the estimation to more types of issues) _The examples above are only a subset of the projects Epics and Stories but the subtasks more or less will follow the same kind of theme_ I understand that more than half of my problem can be down to not planning appropriately the project so any ideas, comments would be welcomed

Dwight McPeak

During our backlog refinement meeting we review our stories to make sure they are "sprint ready". One of the criteria is if the story can be worked in a single sprint or not. If not, we attempt to split the story as many times as needed so that each story can be worked in a sprint. Our sprints are only two weeks so that keeps the stories fairly small. You also want each story to be a standalone piece of work. This can be challenging at times but it's worth the effort to think about the problem and see how you can split it up with these criteria in mind. Your two stories are good in that they address different user needs but the work they ultimately describe has a lot of overlap. I would keep those in mind and maybe write a new set of stories that covers both but also divides up the work into smaller pieces. You could make these wordier as desired, just trying to convey the concept. As a user I want to register for the website. Design the registration page and form Develop and enhance the registration page of our existing standard community platform based on the signed-off designs Write the registration copy Develop the database structure that will hold the profile information Regression Testing Design implementation QA Code Review and Sign-off UAT Client Sign-off Deploy As a website developer I want to verify a user’s email and communicate registration information back to the user Design the email notification templates Get design sign-off Write the email notification copy Write the welcome copy Get copy sign-off Setup domain and email accounts Regression Testing Design implementation QA Code Review and Sign-off UAT Client Sign-off Deploy As a lawyer I want the user to agree to our terms and conditions before completing the registration process. Write the T&Cs Update registration process to display T&C and capture agreement. Add agreement field to DB Regression Testing Design implementation QA Code Review and Sign-off UAT Client Sign-off Deploy In a non-agile approach a developer would tend to look at the registration story and the T&C story and say “It would be more efficient if I just do all of the database work at one time”. This can be a difficult transition to resist that and work them separately. Also recognizing that any one of these stories is not the whole picture and being ok with delivering a working set of code to the client that is only part of the final solution. You may choose to not actually deploy to production until all of the stories are complete but it would be ideal if you at least make the intermediate stories available for user feedback internally. If you work these in sequence you may find that you get valuable feedback from users about the first story that affects the later stories. We hear this a lot "Now that I can see it, here is what I really want". The the first story that includes the actual registration form is actually a multi-page complicated process, it might make sense to split it again in to parts that make sense but can also stand alone.

Dwight McPeak

With that example let me address your specific questions 1. In the above two stories, there is a task for almost every member of the implementation team. Yes, this is a good thing. Each person can put their name on a sub-tasks and show progress. 2. The tasks I listed would fulfil the needs of both stories so they can't be sub-tasks Hopefully the new stories fix this. 3. The time that the tasks will take to be completed will be the length of 2 sprints or more Keep splitting stories and tasks until they meet this criteria. Story – fits in a sprint Sub-tasks – can be completed in a day 4. Assuming that we only estimate the stories there will be nothing to burn down against during the 1st sprint so it would seem we aren't progressing and we can't get an idea of the velocity Velocity is not useful as a team measure until you have completed at least three sprints with a fixed team of people. For a burn down chart to be more useful I think you would have to modify your “sprint ready” definition so that a story is small enough to fit 4 or more of them in a sprint. The other guideline of keeping sub-tasks less than a day will give you an idea of progress during the sprint but you are correct this doesn’t appear anywhere in Jira. Assuming you size these stories consistently you will have a team velocity that may be useful for estimating future sprint capacity. 5. Due to the cross functional nature of the project, there can't be a single owner of each story. We pick a developer and they serve mainly as a point of contact for the story knowing that a lot of people may be involved in a variety of sub-tasks. Everyone that can be assigned a sub-tasks is part of our agile team and speaks during our scrum meetings. 6. Tasks and/or Sub-tasks aren't meant to be Estimated with story points (I know I could configure JIRA so it allows the estimation to more types of issues) Correct, I think more stories helps with this since each story will get an estimate. If they are small enough you can see more granular progress.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-software

capture-for-jira