Creating and Managing Dev Items

A dev item is any feature, improvement, or change you want to measure the impact of. It’s the central unit in VEKTIS — everything else (baselines, releases, post-release data) hangs off a dev item.

Creating a dev item

1. Click “New Dev Item” from the dashboard
2. Fill in the required fields (see table below)
3. Optionally add:
   • Target release date — When you plan to ship (informational, not enforced)
   • Dev tickets — Links to related tickets or PRs (up to 10 URLs, 500 characters each)
   • Notes — Additional context (up to 2,000 characters)
   • Initiatives — Link to one or more initiatives this contributes to
   • Success Threshold — The smallest improvement in your target metric that you’d consider a win (e.g., if tracking conversion rate, a value of 2 means changes smaller than 2 percentage points won’t be flagged)
4. Save the dev item

Field	What to enter	Limits
Title	A clear name for the feature	1–200 characters
Description	What it does and why you’re building it	1–2,000 characters
Target Metric	The specific metric you expect to change	1–200 characters
Target Impact	Your expected change (e.g., “Increase by 15%”)	1–200 characters
Direction	Whether success means the metric goes up or down	Increase or Decrease
Owner	Who’s responsible for tracking this	Select from team members
Success Threshold	The smallest improvement you’d consider a win (optional)	Positive number, same units as target metric

Tip

Write the Target Metric as specifically as possible. “Signup conversion rate” is better than “conversions.” The more specific, the easier it is to measure consistently.

Choosing how VEKTIS measures it

When you create or edit a dev item, VEKTIS asks “How should VEKTIS measure this?” You pick one of two paths:

Option	What it means	Best when
VEKTIS measures it for me	Reads results from your product automatically. You set it up once, and measurements flow in on their own.	Your product already sends the relevant activity to VEKTIS.
I’ll enter results myself	You type values into the dashboard after each release.	The metric lives somewhere VEKTIS doesn’t see — a spreadsheet, an analytics tool, a manual report.

If you choose VEKTIS measures it for me, two more fields appear:

• Feature ID — the tag your product uses when it sends this feature’s activity to VEKTIS. It must match exactly — capital letters and dashes count. See Feature IDs.
• Value Type — how VEKTIS should work the number out: Count occurrences, Conversion rate, Time to complete, Overall activity, or Revenue (manual). See Measurement Types.

If you choose I’ll enter results myself, there’s nothing more to configure — you add each measurement by hand as you go.

Note

You can switch a dev item from automatic to manual measurement later. Because automatic measurement depends on the Feature ID and Value Type, switching to manual removes them (VEKTIS confirms before it does). You can re-add them if you switch back.

Dev item statuses

Every dev item moves through a lifecycle:

Status	What it means	What you can do
Planning	Gathering requirements and defining the metric	Add/edit baselines, mark as released
Development	Feature is being built	Add/edit baselines, mark as released
Measuring	Feature is live, collecting post-release data	Add baselines (pre-release dates), add post-release metrics
Complete	Measurement period is over	Add/edit post-release metrics, view results
Archived	No longer actively tracked	View only — no changes allowed

See Dev Item Lifecycle for the full status transition diagram.

Note

You can move backward in the lifecycle (e.g., from Measuring back to Development) if needed — except from Archived, which is a final state.

Editing a dev item

Open any dev item and click Edit to update its fields. All fields from creation are editable, with the same validation rules.

Changes to the dev item’s fields (title, description, metric, etc.) don’t affect existing baseline or post-release data — those are tracked separately.

The measurement workflow

Here’s the typical lifecycle of a dev item:

1. Create the dev item with your target metric and direction
2. Collect baselines — VEKTIS gathers pre-release data points automatically, or you add them yourself (aim for 4+)
3. Mark as released — Record the actual release date
4. Measure impact — Post-release data points arrive automatically, or you add them, over the following weeks
5. Review results — Check impact badges and confidence levels
6. Complete — Mark as complete when you have enough data to draw conclusions
7. Archive (optional) — Move to archived when you no longer need to reference it

Linking to initiatives

Dev items can be linked to one or more initiatives — larger goals or projects that multiple features contribute to. You can set these when creating or editing a dev item.

See Organizing Work with Initiatives for details.

Tips

• One metric per dev item — If a feature affects multiple metrics, create separate dev items for each. This keeps the before-and-after comparison clean.
• Be prescriptive with target impact — “Increase by 15%” is better than “Improve.” It gives you a benchmark to evaluate against.
• Start collecting baselines early — Don’t wait until development is done. The earlier you start, the stronger your baseline.
• Use notes liberally — Future you will thank present you for the context.