🤔 I.N.V.E.S.T. like a pill for the pain of misunderstanding
Today I want to touch on project management a little more, let’s talk to you about I.N.V.E.S.T. principle.
I.N.V.E.S.T. used as a filter for tasks so as not to drag “everything in a row” into the current sprint. Essentially these are: Independent, Negotiable, Valuable, Estimable, Small, Testable tasks that help us grade our workload and understand what they want from us, since you will constantly be faced with cases: “I don’t understand where we are going,” “I want everything and everyone,” “it’s not clear what needs to be done,” etc.
In AppSec, as elsewhere, “make security secure” often comes up. These are not tasks, but a real headache. I.N.V.E.S.T. helps turn pain into normal user‑story and technical tasks, that is:
• understandable to the team
• giving a measurable effect
• which can actually be closed in a sprint
• and check that they worked
How does it work?
• I - Independent
History must live separately: you can take it and do it without half the department
Bad example: “Make secure login, registration, password recovery and profiles”
I.N.V.E.S.T.: “Add rate limiting on POST /login with blocking logging”
• N—Negotiable
The story is like an invitation to a conversation, where details can be clarified with the team before the start of the sprint
If the task sounds like “strictly according to GOST XXX, no options” - this is more likely a policy than a user story
•V—Valuable
It should be clear to whom and what value the story provides: the user, business, security
Example: “Enable another scanner” is not a value.
I.N.V.E.S.T.: “Reduce critical vulnerabilities in the product by adding Quality Gate at the CI level” - becomes a value
• E - Estimable
The team must understand the volume: at least the order - day, three, sprint
If the story sounds like “implement DevSecOps,” it first needs to be cut down to pieces that can be evaluated (for example, “connect SAST to project X”) and if you don’t conduct a review or analysis, and they tell you “calculate something there yourself and suggest it,” this is really bad
• S - Small
The story should fit into one sprint and, preferably, take up no more than 25–50% of the sprint per team
We cut everything that sounds like “rewrite the authorization module” into separate steps: login, MFA, blocking, audit
• T - Testable
The story must have clear acceptance criteria: how will we understand that it is done - I previously wrote about Win Conditions/ Fail Conditions
That is, “Make it safer” is not tested, but “if 5 incorrect logins, the account is blocked for 15 minutes, the event is sent to SIEM” - is tested
How to approach tasks correctly?
You take any wish and run it through INVEST:
• Is it independent from everything else?
• Can it be discussed and reformulated before the sprint?
• Is it clear what benefits it brings?
• Can the team evaluate it?
• Does it fit into one sprint?
• Can we clearly verify the result by testing/monitoring?
If the answer to at least one point is “no,” the story is still raw, and it’s better to finish it before pulling it into a sprint
Template
## Heading
[AppSec] Briefly and specifically: what we do and where
## User story
As <role/client> I want <what exactly> to <what measurable benefit/risk>
Examples:
- As the owner of the auth-service, I want to limit the number of login attempts to reduce the risk of password brute force and account takeover.
- As an AppSec engineer, I want to enable blocking Quality Gate for critical vulnerabilities so as not to release new critical holes into production.
## Context (Define)
- Current behavior/problem:
- Now...
- Affected systems/services:
- auth-service, gateway, ...
- Risks/incidents/motivation:
- There were X incidents/Y vulnerabilities found...
## INVEST criteria
- **Independent**
- **Valuable**
- **Estimable & Small**
- **Testable**
## Acceptance criteria (Testable)
Given/When/Then format or list
## Technical notes (Negotiable)
- Suggested approach (can be changed based on discussion):
- Limitations and assumptions:
## Metrics / control (Control)
- What and how we measure after implementation:
- Where to look:
#pmi #reco #specialty #appsec #humanres #paper