1

I need to track progress of some activities that doesn't have clear functional requirements, like Performance Testing, Anomaly Testing, Security Testing, etc.. what would you recommend?

For functional requirements, we create tickets in Jira, so we track development and testing there.

3
  • 4
    What prevents you from creating Jira tickets for these activities? Something like "Perform security testing", "Do performance testing", etc. seem like valid tickets to me.
    – Bogdan
    May 29, 2022 at 15:49
  • 2
    Why isn't performance a clear functional requirement? How do you measure performance if it's not a functional requirement?
    – nvoigt
    May 29, 2022 at 19:52
  • @nvoigt While asking whether these things are legitimately non-functional requirements or not is a great question, many requirements are really attributes of the overall system or its behavior rather than specific "features" that define what a product's should do rather than how it should do them. In some systems, this is a gray area. Terminology aside, this just begs the question of how you measure requirements that haven't been defined with the same rigor as the bullet-point functionality you often see on a customer-facing sales sheet.
    – Todd A. Jacobs
    Jun 5, 2022 at 4:08

1 Answer 1

1

TL;DR

Classifying testing or security as non-functional requirements may or may not be appropriate for your project. Regardless, all work related to a project's expected outcomes can and should be decomposed into estimable work items that are either "done" or "not done" when evaluating progress or deliverables.

How to Manage Outcome-Based Delivery for Testing, Security, and Other Activities

Even if they are classified as "non-functional" requirements because they are not product features in the way that many product or project managers typically think about these things from a development-focused perspective, they are still work and should be tracked accordingly. All of the things you mentioned should have measurable PKIs and OKRs, or at the very least desired outcomes for each activity. If they don't, then you're either not involving the correct subject matter experts in planning, or your project is doing things that were not (and perhaps still are not) appropriately defined at the strategic or tactical levels for the project.

For example:

  • For "performance testing" to be successful, what components will be measured, how will the measurements be evaluated, and what is the minimum level of performance that must be met?
  • If "anomaly testing" is performed, what methodologies will be used and how many anomalies (or classifications of anomalies) will determine of the overall result is satisfactory or not?
  • If "security testing" is performed, what are the standards or other baselines that need to be met to report success?

If these things are gating criteria for the project, then they should be part of the "Definition of Done" and tracked as work items. If they aren't, then this would appear to be some sort of post facto scope creep. In the former case, these items should have been part of your project initiation and planning; in the latter case, the work items should be treated as new requirements within whatever change control processes have been established for the project.

Involve Subject Matter Experts

In either case, you clearly need to involve subject matter experts (SMEs) for the activities that are not accurately reflected in the current plan. The SMEs should ideally be the people who will actually be doing the work, or you risk a mismatch between abstract estimates and the knowledge and skill sets of the actual task performers. The SMEs can help:

  1. define the work required to meet each outcome or objective,
  2. identify how the work will be tracked and measured, and
  3. estimate the level of effort or time it would likely take to perform each activity within a clearly-defined set of assumptions.

In other words, these things should be planned, estimated, scheduled, and tracked the same way you would track any other project-related requirements. The only difference is that it seems like the project currently lacks the required expertise within the team as presently constituted. That means you'll either need to add those people and skills to the team, or leverage outside resources to help the project fill any gaps.

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.