Keeping track of the current state of a very dynamic, changing implementation/project

[Robert Knopfler]

We're a services/implementation provider, and we have a couple different approaches and processes that we abide to when starting up a new project for a client.

Building out a new implementation can take several months with a very large scope, so after we do a number of rounds with the client to agree upon a fairly detailed scope of work, these requirements be represented in a "Functional Specs" doc that lives in Confluence. Client will sign off, JIRA tickets will be generated out of this, and our dev team is off and running.

But once we get to building, requirements get tweaked, additional features will be added, and certain things won't get built as as result. Managing this level of agility is not a problem, but our PMs are looking for help in ways to track this very dynamic, changing implementation without having to go back to the original FS Doc, remove language, write in new language, etc. 

Are there any features between confluence and jira that might make it easier to point somewhere at any given time, and understand with some level of detail "what the current implementation is"? It might be as simple as rolling up different tickets under epics and exporting those views to a confluence doc, but I'm unsure if that's the right move. Any other features or approaches between JIRA and Confluence out there that folks have success utilizing?

Would love any suggestions

[Dave Mathijs]

Hi @Robert Knopfler welcome to the Atlassian Community!

Interesting question you have there.

When talking about "the current implementation", I would consider the stories/epics that are effectively developed (an deployed/released), so "done" from a development point of view.

I support you have user story acceptance criteria as they specify the conditions under which a user story is considered complete and the functionality meets the required standards.

For every tweak, changes business requirements or additional feature, you would create a new issue, right?

[Robert Knopfler]

Hi @Dave Mathijs thank you for the input. My intuition is going to the same place, as far as relying on deployed or "done" tickets to effectively dictate the source of truth as far as what solution, and underlying features/functionality have been built.

You're correct on tweaks and changing requirements - we create a new issue and log work/testing/etc within that jira ticket.

The problem is less about managing that work, and more so on how we point to a place at any given time to see a contextual summary of what the solution has become. The solve might just be managing Epics really well, and creating a Confluence page that is roll up of all the different Epics and underlying tickets. I *think* Confluence has a feature that allows a dynamic breakdown of Epics/underlying tickets but I haven't fully checked yet. It also might be easier to see in JIRA, but then you lose the overlying contextual element we'd probably want