1

We are working on a project that (roughly) consists of following parts:

  • back-end application,
  • central communication server, and
  • client applications for several platforms.

Our "team", on the other hand, consists of several one-man teams, each person working on a different part of the project.

We are using JIRA+Agile. We have created a single project in JIRA, and a component is created for each above mentioned part. Each issue is assigned to correct component(s). This goes mostly for Epics and Story issue types, where it actually makes sense.

We write user stories in such a fashion so that PO can see clearly what is gained by completing this story (i.e. allow user to see his inbox). We tend to create stories that are granular enough so that they can be reasonably completed within a sprint. Actual development tasks are created as sub-tasks of main Story issue. We estimate our stories by playing Planning Poker, even though different people might really have different amounts of work involved in each story, and it makes sense for us.

This approach allows us to also track progress of implementing complex, new functionality across all components (Epics) by breaking it down into discrete Stories, and then creating sub-tasks for each task that needs to be performed. As tasks are resolved, stories auto-complete themselves, which is all nice and sweet, and we are generally satisfied with how it all works.

However... We are going to build another client application for a different platform (part of the same project). The work we will need to perform is already well defined in existing Stories, as most of that work has been completed in other client applications for other platforms. The trouble is, all those stories are already completed! And, furthermore, amount of story points for each Story is estimated long ago...

One way is to duplicate all user stories, regarding existing client apps, redefine them a bit to make it clear which platform they are targeting, re-estimate them for that platform.. Another way is to basically create a user story for each piece of work that needs to be done on each platform, BUT, this approach will break entire process from the point of view of PO, thus breaking desired functionality into several (probably not equally readable) stories... Maybe it was a mistake to create a single project for all components? But, it was driven by the fact that client apps for each platform would basically replicate each other at least 90%, so there would be a lot of overlap and duplicated issues...

Question: What would be a good way to organise such a project using JIRA and Agile, that would allow us to work in similar way that we already do, but that would also allow us greater flexibility when adding new components that would basically have to replicate functionality already implemented in other client apps?

Thanks for reading ;)

1
  • The answer to your question is best answered here on this post: Hope that helps! Commented Oct 11, 2014 at 9:16

2 Answers 2

1

tl;dr

Build reusable components & Organizational Process Assets

One way is to duplicate all user stories, regarding existing client apps, redefine them a bit to make it clear which platform they are targeting, re-estimate them for that platform..

First, CodeGnome's law; don't worry about technology (Jira) until you've decided what you want to do and how you want to do it.

Second, if you have to write client applications for multiple platforms, don't worry about the technology until you've decided what to do and how to do it. Design the client server architecture, then design the client capabilities, then decompose these into functional and non-functional requirements. Then plan how to achieve those requirements for each platform.

Notice how you have automatically built a reference class for estimation? Start work on Platform 1; when you estimate platform 2, determine how much of the difference between estimate and actual will affect your estimate for platform 2. Repeat for platform N.

If you begin by creating user stories for every piece of work, you undermine the value of re-use.

1

You can Clone/Copy an entire JIRA project

As @Mark C. Wallace pointed out, decide on what you want to do and how you want to do it first. For example, in the process of building the first client application, your Product Owner might have thought of how to improve on the designs/flows. Your development team might have learned a few things about what not to do. By simply copying the stories, the team loses the opportunity to do some fresh thinking in the light of experience and improve things.

However, after due consideration for the above, if you want to bulk copy stories, looks like there are some possibilities. We have setup Agile boards such a way that we can pull stories from multiple projects. In this setup, though I have not used it, I understand I can Clone/Copy an entire JIRA project using the Jira Command Line Interface (JCLI).

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.