Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Struggling to manage depedencies and new product roll out.

david-guild
Contributor
June 28, 2018

Hello,

Implementing Jira and trying to move from modified waterfall to agile. We are working on a mobile project where we have several stages of ui/ux (wire frame, low fidelity, high fidelity), we have the front end layer that connects to the networking / interface layer that talks to the Api layer.

We do Epics into User Stories into tasks/subtasks. We started hanging 4 tasks off each user story (ui, screens, interface, api) to track dependicies, but has turned out to be a mess for the following reasons:

  • One Api usually handles multiple stories, which means a lot of relating links.
  • One Screen usually handles multiple stories
  • Screens / ux has muultiple states (wireframe, low and high fidelity)
  • UX design usually covers multiple epics
  • Finally we started splitting user stories by scenario so 1 story with 3 scenarios now becomes 3 stories/issues. Which furture increases the complexity issue.

The splitlling the user story is particularly distrubbing because the issues are the source of truth for the stories as the team did not want to persist the user story in confluence. I like the splitting in principal, but I dont like not being able to read the entirety of a user story in one place.

We set up the linking so we could report out bockers. Screen is blocked by interface, which is blocked by api, which might be blocked by a 3rd party service.

We defined Done as anything that has gone through QA and is ready for release. We are not technically releasing cause it is a new product and we are building the mvp so it is all or nothing.

UI/UX did wire frames for the first few sprints, low fidelity for the following sprints, and is now working on high fidelity for the final sprints.

The effect of all of this is that user stories are never completed. I think the entirety of this probmles stems from having issue type story be, and only be, the actual user story/scenario.

I am inclined to move stories into confluence, have another issue type be the container for the full user story, then have discrete user stories like :

  • Feature 1 = full user story
  • Story = Feature 1, Story  1, scenario 2, ui wire frame.
  • Story = Feature 1, Story 1, interface
  • Story = Feature 1, api

Feature stays open till every thing is done, and each story can be completed.

Or something like that. Currently, since stories are never completed, the PO doesn't get a clear picture of where we are, and we are getting lost in the complexity.

I feel we are just missing a concept or two that would fix this. We started grouping api / interfaces into component by Service ( 3rd party 1, 3rd party 2, internal 1, etc, etc) and I think that is going to help long term, but still missing something.

Thanks in aadvance for your thoughts and suggestions.

 

 

 

0 answers

Suggest an answer

Log in or Sign up to answer