I work in a company and we use TargetProcess (a Jira fork) as Project Management to manage our work in Agile style (Scrum).

It works quite well. We write issues ("Epic", "Feature", "User Story" and "Tasks") and when issues are in the backlog and not "Done", it's easy to found what we need to do.

The problem is when issues are marked done, they are lost in the huge "Done Backlog". At the present time, we have about 50'000 issues.

So we have frequently conversation like :

  • "Do you remember when we worked on this US ? I have the same problem again."
  • "Oh, yes I remember. But I can't find the US."

So we create the same US and have to investigate again despite the fact we already have the solution in our Project Management. The problem is we can't perform efficiency search in 50'000 issues and hundred of Epic.

How to do to find information in done issues ? Maybe software like Jira / TarjetProcess / kanbanize / BacLog and other softwares are only for the current job and are not designed to work efficiency with old done issues ?


Maybe we do not use Project Management in the right way ? Project Management are designed to manage current work and not old ?

Maybe we need to write link to the issue in the documentation ? and the documentation is the actual state of the art and the issue explains the reason of the decision ?

The big problem is I have no idea how to tidy up done issues.


Two things stand out:

  • Tools for work management or project management aren't necessarily the best for knowledge management.
  • Traceability can go a long way.

I'm not familiar with Targetprocess as a tool, but I took a quick look at their website. It looks like a generic issue tracker. Often, issue trackers are good for identifying work that needs to happen and prioritizing it and assigning it to teams or individuals. But often, it's difficult to search and sort all of the done issues.

Rather than using your project management or issue tracking tool, consider a tool that is more focused on knowledge management. There are different options. For most kinds of projects, a wiki may be a good choice. For software projects, some information could be kept inside of a /docs directory within the project. For large enterprises, document management tools may also be beneficial.

In addition to a knowledge management tool, bidirectional traceability between the issue tracker and the work and the references in the knowledge management tool is extremely helpful. For example, I use the Atlassian suite (Jira, Confluence, and Bitbucket) as well as GitHub (for issues, wiki, and source code). Given an issue, I can find other issues where it's mentioned or linked, wiki pages that reference the issue, and source code (including plain text documentation files). I can also navigate from history in source code files to the issues associated with those changes and back to documentation. This helps tie together information that may live in various places through not only searching, but also linking.

I'm not sure that tidying up your done issues is appropriate, but you can start by creating documentation and linking what you can when it's possible. When you have questions, start by searching through your existing documentation and done issues and link what is possible. It is a balancing act between backfilling documentation and linking work and making progress on new and future work. Focus on what you do going forward.

  • Thanks for your opinion. I came at the same conclusion that I need to use another tool like a Wiki / documentation (or Confluence with Atlassian) to better manager done issue. Maybe than actual Project Management are only design to be efficiency with work in progress. – Vincent LE GARREC Apr 12 '20 at 13:09

Effectiveness of keyword search is based on search engine and index

Jira uses Apache Lucene as the search engine. Here is an article describing how it builds and maintains a keyword index. Jira has its own search language called Jira Query Language (JQL). It has a fairly good basic search and an advanced search with more capabilities.

Check the following:

  • Which search engine is used by TargetProcess and what is its process.
  • How does it build the index?
  • Can you manually kick-off the process that will rebuild the index?
  • Is there a way to configure the search engine and the index that will improve the effectiveness of the search?
  • Can you get TargetProcess to conduct a short workshop for your team on how to do advanced keyword search?
  • Is this self-hosted by you? If the searches are running slow, it may need more processing power.

Apache Lucene (and similar other search engines) are capable of handling much larger texts. A 50,000 issue Done pool should not be such a big problem.



Other answers may address how to manage historical issues with JIRA-like systems, but I will take the approach of calling out the implied anti-pattern of trying to recall past work within an iterative development process in the first place. I'll address why I think it's an anti-pattern, and what I think you ought to do instead.

Pulling Forward from Historical Work: An Agile Anti-Pattern

In a properly-implemented agile development framework, each iteration is a cycle or time box that is ephemeral. Historical work should not be a first-class artifict because:

  1. Your code base and market conditions evolve, so the work needed should never be an exact duplicate of some past work performed.
  2. User stories (as opposed to tasks) should capture objectives and level of effort from the current state to some future state. The steps and effort in the past are unlikely to be an exact duplicate of what's needed now.
  3. Repeatable user stories are more likely to be tasks, and driving that level of granularity is rarely a good idea. Tasks should flow naturally from the goal of a well-crafted user story.
  4. Recurring bugs are often a symptom of an incomplete Definition of Done, and more specifically from a lack of regression-testing or continuous integration practices.
  5. Living documentation belongs in tests and code, not in historical user stories or tasks.

There are other reasons, too. Suffice it to say that if you're thinking "We've solved for this thing before," you ought to question a process where you're having to re-solve for the same thing in a way where some historical approach is still valid. In incremental and iterative methodologies, you may have similar features or objectives, but each one should plan from where the product is today rather than where it was at some point in the past.

What to Do Instead

Without knowing the specifics of your product or the stories that keep popping up, this advice will be somewhat generic. Still, it should help you to refine the team's process going forward.

  1. Treat your starting point for each iteration or work increment as a new baseline.
  2. Plan the work and measure the effort from your new baseline, not some past baseline.
  3. Ensure that the team uses a test-first approach to meet the Definition of Done.
  4. Make sure that tests (and comments in your code, if it's software) are useful in providing self-documenting product behavior.
  5. Automate recurring tasks and procedures as much as possible.
  6. Use source code management or other change management tools to track what changed and why.
  7. If you need a knowledge base, develop one. Don't misuse planning artifacts (e.g. backlog items or user stories) for knowledge transfer.
  8. Develop a test suite with self-documenting regression and acceptance tests to describe the expected behavior of your system, and to capture any changes to that behavior.
  9. Update your self-documenting tests when the behavior of your system changes.
  10. Bring up challenges with recurring work, recurring bugs, or knowledge retrieval at a retrospective to crowdsource a solution suitable for the team's current project.

In short, while you may continuously refine aspects of your product, your process should be iterative or incremental with a new baseline each cycle. Good user stories carry context, so at minimum that context needs to be updated each time you refine a feature. If your process doesn't currently support that, then that's grist for the mill within your framework's planning and inspect-and-adapt events.

  • Thanks for your feedback. "If you need a knowledge base, develop one. Don't misuse planning artifacts (e.g. backlog items or user stories) for knowledge transfer." I think we are doing exactly that. We have documentation in our network but nobody can find it when we need it. So it's easier to find the ticket to get information instead of reading outdated doc. I think I will talk to my scrum master about this problem. – Vincent LE GARREC Apr 13 '20 at 16:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.