ISO how to organize a project so you can easily see all remaining work for User Story's and overall project

TLDR: Does anyone know a way to organize requirements (User Stories & Acceptance Criteria) to tasks in a way to make sure we’re on track, what work remains, and any holes (For example: If there is work being done that doesn’t directly correlate with a User Story). Dependencies help, but they really hard to keep track of if you’re just looking to see remaining work for tasks and the whole project.

I have recently setup weekly syncs among developers and stakeholders to make sure we’re on track and all work being done by my team directly correlates to specific requirements (User Stories and/or Acceptance Criteria).

I am having a hard time figuring out the best way to connect User Stories/Acceptance Criteria to tasked work in a way that is easy to see (1) estimated work to be done (2) what remains on for not only US/AC, but the overall project.

I’ve tried Portfolios, Sections, Subtasks, and dependencies, but still can’t find a way to easily paint my story. I am currently navigating between 3-4 projects:

  1. Project Name - Development. Sectioned off by Iteration, with tasks that need to be done. (These tasks are then put into Sprints)

  2. Project Name - User Stories. Sectioned off by Iteration, with User Stories as tasks, Acceptance Criteria as subtasks, and tasks from the project above added as dependencies.

  3. Project Name - Dev & Product. Sectioned off by PM work and timelines.

  4. Sprint Sectioned off by team, with tasks being worked within the Sprint!

Max Retries User Stories|690x326

1 Like

I’m working on a plugin for Asana, that helps people run web development projects. It won’t help with your question directly, but I’m always keen to understand how other people manage web dev on Asana.

Below is how I’ve done it in the past - let me know the gaps between this and what you’re trying to achieve…

For one reason or another, I’ve never really needed Portofolios.

Everything for the one project is in one Project

Sprints and Iterations are same thing, using Sections

User Stories are a type of Task. “Non-User Stories” are another type of task. Bugs are another.

Acceptance Criteria (or Definition of Done) are details that tell us how much is involved in a task. These can be Subtasks or details in the task the description.

So Tasks (whether its a User Story or not) get allocated to a Sprint by dragging between Sections. Anything not in a Section is in the backlog.

Some people want to keep non-user stories separate to the Sprint or backlog … I never understood this - they are tasks that need to get done, so they should be planned for like all the other tasks. Labels or Assignee can be used to filter Sprint tasks if they need to be viewed separately.

Estimates, progress, discussion etc take place at the Task level. Progress is tracked by labels - to do, doing, testing, blocked, done etc.

Traceability back to Requirements (when one requirement has multiple user stories) can be achieved with custom fields drop down list of Requirements.

I hope that helps.

In case you’re interested, the plugin I’m working on is a fast way to get feedback/create tasks and and easy way to view progress, using virtual post-it notes. https://getsifta.com

3 Likes

I know I’m late to this comment but it was super helpful. Thanks Ben.