Feature · Agile Workflow

An agile workflow your whole revenue team can run on.

Boards, sprints, backlog, capacity, dependencies, and automations in one place. Not a Jira stack bolted onto a CRM, a native agile surface shared by sales ops, marketing, and the project team so cross-functional work has one home.

Start free trial See pricing
What agile workflow means at Strkr

A real agile surface, not a Trello clone glued to a CRM.

Agile is a specific set of commitments: short iterations, visible work, continuous feedback, and a backlog that reflects actual priority. Most CRMs that advertise agile capability ship a shared kanban board and stop there. Strkr's Projects module is a full agile surface: sprints with start and end dates, capacity math per assignee, backlog grooming, dependency links, retrospective tracking, and automations that move work between states on real triggers.

Sprints

Timeboxed iterations with a start and an end.

A sprint has a name, a date range, a goal, and a point commitment. Issues move into the sprint during planning and lock on start. The sprint strip across the board shows days remaining and point burn. When the sprint ends it archives automatically so the next one starts clean. The classic agile cadence, built into the surface rather than mimicked.

Boards

Columns, swimlanes, and density you control.

The board view ships with a density popover (compact, comfortable, roomy), a color-by selector (status, priority, type, assignee), and a group-by (status, assignee, epic, sprint). Swimlanes keep assignee-based or epic-based views legible even when the team is pushing 60 open issues. The configuration persists per user.

Backlog

Grooming surface designed for the Monday ritual.

The backlog list shows every issue not yet in a sprint, with inline edit for priority, points, assignee, and labels. Collapsible groups per epic or per label. Multi-select and bulk assign. Drag an issue into the next sprint without leaving the page. The surface replaces the sprint-planning spreadsheet most teams keep on the side.

Issue types

Story, task, bug, spike, epic, custom.

Default types cover the usual kit (story, task, bug, spike, epic) and admins can define new ones with their own icon, color, and workflow. A delivery team runs stories and bugs. A revenue team runs tasks and campaigns. The same board model carries both because the type system is open.

Statuses and transitions

Workflow transitions scoped per issue type.

Each issue type carries its own status set with transitions between them. Story might run Open to In Progress to In Review to Done. Bug might run Open to Triage to In Progress to Verified to Closed. Transitions can require fields, trigger automations, or notify specific users. The workflow is editable in Admin without a developer.

Dependencies

Blockers, blocks, and involves-me surfaces.

Link an issue as blocked by another or blocking another. The surface shows the chain so the sprint-planning conversation has the full picture. A dedicated Dependencies page lists every pair with an Involves-Me tab for the current user. No more sprint burndown that stalls because a blocker was never surfaced.

Capacity and planning

The math that keeps sprints honest.

Agile planning falls apart when the team commits to 80 points of work and three members are on PTO. Capacity math is the usually-missing piece. Strkr ships it as a first-class surface: effective points per assignee, OOO ranges per person, per-sprint overrides, and a capacity drawer that shows the burndown next to the commitment before the sprint is locked in.

Capacity drawer

A side panel that math-checks the sprint.

Click Capacity on the sprint and a drawer opens with each assignee's effective points based on their default velocity, OOO ranges in the sprint window, and any per-sprint override. The team's total effective capacity sits next to the total committed points. The drawer flags the delta so the overcommit is visible before the sprint starts.

OOO ranges

PTO entered once, respected everywhere.

Each team member can log OOO date ranges in their profile. The capacity math subtracts those days from the sprint window. If a rep has three days off in a two-week sprint, their effective points drop to 70 percent of their default. No more "I forgot Sarah was out that week" at sprint review.

Weekday math

Only Mon to Fri count toward capacity.

The capacity calculation treats weekends as zero-work by default (configurable per team). A two-week sprint has 10 working days, not 14. Teams running weekend on-call rotations can mark Saturday and Sunday as working days per person. The math follows real human schedules, not calendar days.

Per-assignee bars

See individual load during planning.

During backlog-to-sprint planning, a horizontal bar per assignee shows committed-points-vs-capacity. Drag issues in and the bars update in real time. Reassign an issue and both bars update. The team sees imbalance (one person at 150 percent, another at 40) before the sprint starts, not three days in.

Sprint goal

The one-sentence commitment at the top.

Every sprint carries a goal, a one-sentence description of what shipping this sprint means. The goal shows at the top of the board and in the sprint strip. During the sprint, when someone asks "should we take this urgent request?", the goal is the answer, yes if it serves the goal, no if it pulls focus. A simple field, loaded with meaning.

Burndown chart

Points remaining versus the ideal line.

The sprint tab shows a burndown chart: remaining points per day against the ideal diagonal. Flat lines mean work added or re-estimated mid-sprint. Steep drops mean a batch of issues closed. The team reads the chart at daily standup to spot risk before the final day.

Automation and triggers

The workflow runs itself between standups.

The repetitive agile tasks (reassigning on blocker, posting a Slack note on status change, moving an issue to Done when a PR merges) are not what the team joined to do. Strkr Flows provides the automation layer: triggers from the Projects module, actions anywhere in Strkr, and the full event history for debugging when something misfires.

Status-change trigger

projects.workflow.status_changed.

Every status transition fires an event. Build a Flow that catches it: when an issue moves from In Review to Done, post the issue summary to the team's Slack channel. When a bug moves to Verified, email the reporter. The trigger payload includes the issue, the old status, the new status, and the actor, so conditional branching is clean.

Transition rules

Gates and side-effects per transition.

A transition can require a field to be set (close reason, QA sign-off), auto-set a field (closed-at timestamp), or require a user with a specific permission to execute it. The rule lives on the transition, not scattered across code. Admins see every rule in the workflow editor at a glance.

Scoped automations

Project-level and workspace-level flows.

A Flow can be scoped to a single project (built on its Automations tab) or to the whole workspace (built in /admin/workflows). Project-scoped flows cover the one team's rituals. Workspace flows cover org-wide behaviors like escalating a Severity-1 bug to the on-call rotation regardless of which project filed it.

Audit history

Every automation run, timestamped and inspectable.

Each Flow run writes a record with the trigger payload, the condition evaluation, the actions executed, and any error. If an auto-assign misfires, click into the run to see which rule triggered, which branch evaluated true, and where the failure landed. Debugging is a scroll, not an archaeology dig.

Cross-module triggers

A deal change can move an issue.

The CRM, Marketing, Messaging, and Projects modules all share the Flow runtime. A deal moving to Closed Won can auto-create implementation issues in the Projects module. A campaign reaching 10,000 subscribers can create a Projects task to design the next tier. The event bus is one, so the automation lattice spans the full suite.

Native integrations

Slack, Google, Microsoft, Salesforce, native.

Every connection ships as first-party code with webhooks and KMS-encrypted credentials. Slack notifications, Google Calendar event creation, Microsoft Teams posts, Salesforce bidirectional sync, every integration is wired to the Flow runtime. No third-party automation middleman, no monthly recurring glue layer.

Views that match how the team thinks

One agile surface, multiple ways to read it.

Different roles see different cuts of the same work. The scrum master lives on the board. The PM lives on the roadmap. The individual contributor lives on My Issues. The exec lives on Reports. Strkr's Projects module exposes a view per role rather than forcing everyone through the same board.

Board view

The daily driver.

The default view for most team members. Columns by status, cards grouped by assignee or epic, density switch, color-by selector, sprint strip across the top with countdown and burn. The classic agile board, native to Strkr rather than embedded from Jira.

Roadmap view

Epic bars across a Gantt timeline.

The roadmap shows every epic as a horizontal bar across a timeline. Sprint swimlane below. Today marker vertical. Drag an epic to reschedule, drag its end-handle to extend. The PM uses the roadmap to answer "what are we delivering this quarter" without opening a slide deck.

Backlog view

The grooming list, sortable and filterable.

A dense list of unscheduled issues. Inline edit for priority, points, assignee, labels, type. Collapsible groups. Multi-select bulk-update. Drag into the next sprint. The scrum master runs the Thursday grooming session on this page while screen-sharing. The team edits with them.

Sprint view

The in-flight cadence surface.

Per-sprint page with metric cards (committed points, completed, in progress, blocked), burndown chart, by-assignee bars, and the full board scoped to the sprintId. The daily standup opens here. The retrospective closes here.

My Issues

The IC's home page.

Search box, saved view bar, quick filters (Assigned to me, Reported by me, Blocked, Due this week, Overdue, In Review, Mentioned), cross-project new-issue picker. The individual contributor opens Strkr to this page and sees exactly what they are expected to move today.

Reports and Activity

The lens the exec wants.

Reports page: project filter, period toggle (30d / 90d / YTD), CSV export, four KPI cards (throughput, cycle time, lead time, change failure). Activity page: debounced search, tone-tinted icons for status changes, assignments, comments. The lightweight BI the leader checks on Thursday afternoon.

Agile workflow examples

How real teams run on this surface.

Agile is a shape, not a prescription. Different teams pour different work into the same ritual. These are the patterns we see most often from teams running their agile workflow in Strkr, each a template a sales ops lead or project manager can set up in an afternoon.

Software delivery

Classic Scrum, two-week sprints.

Story and bug issue types, five-column workflow (Backlog, In Progress, In Review, QA, Done), two-week sprints with Monday planning and Friday demo. Burndown on the sprint page, retrospective notes on an issue of type Spike. The pattern Jira made famous, native in Strkr with none of the configuration tax.

Marketing campaigns

Campaign as epic, assets as stories.

Each campaign is an epic. Landing page, three emails, a social post, and a performance review are stories inside it. The marketing team runs the campaign in a sprint. Launch date is the sprint end. The campaign retrospective is the first story in the next sprint.

Sales operations

Quota changes, pipeline reports, playbook updates.

Sales ops runs a rolling backlog of changes requested by sales leadership (new field, new report, new workflow). Items are tasks. Sprints are two weeks. Priority is set in grooming based on which ask unblocks the most reps. The surface replaces the sales ops ticket queue most teams keep in a spreadsheet.

Customer success

Renewal risk as issues.

Every at-risk account opens as an issue with the account linked (the Projects module cross-references the CRM Account record). CS runs a weekly sprint of save motions. Each issue has owner, due date, playbook link, status. Save rate is the Reports page metric that trends across sprints.

Product onboarding

Implementation projects per customer.

A new paying customer gets a project cloned from a template. Standard set of onboarding issues (kickoff, data import, SSO config, pilot cohort, launch review). The implementation manager runs sprints across their portfolio of concurrent onboardings. Blockers surface on the shared Dependencies page.

Internal IT

Request intake, triage, delivery.

IT runs intake via a shared project with a Request issue type. The on-call engineer triages new requests daily, estimating points and assigning to a sprint. Severity-1 jumps the queue via automation. Monthly reports surface request volume, cycle time, and backlog depth.

Compared to the alternatives

What this surface replaces for a revenue org.

Most mid-market revenue orgs run their agile workflow on a stack: Jira for software delivery, Monday or Asana for marketing campaigns, a sales-ops spreadsheet for internal requests, and a Google Doc for cross-functional roadmap. Strkr's Projects module replaces the stack because every team shares the same event bus, the same permission model, and the same automation runtime.

Jira

Powerful, specialized to engineering.

Jira is the agile gold standard for software delivery. The tradeoff is that it was built for engineers and the configuration surface shows it. Marketing teams routinely abandon Jira after a quarter. For a revenue org that wants one agile home across sales ops, marketing, and delivery, Jira solves one slice and leaves the rest.

Asana

Approachable, light on math.

Asana is the easiest to adopt for non-engineering teams. The agile features (sprints, points, burndown, capacity) exist but shallow. A delivery team outgrows Asana in a year. A revenue org can use Asana for marketing and sales ops without pain, but adding engineering means a second tool.

Monday

Flexible, workflow-heavy, expensive at scale.

Monday's board model is the most flexible in the category. The per-seat pricing climbs quickly when you need the formula columns, the dependency features, or the time tracking. Agile-specific features (burndown, capacity, retrospective templates) are available but assembled from building blocks rather than shipped as a shape.

Linear

Beautiful, opinionated, engineering-centric.

Linear is the sharpest agile tool for engineering teams in the last five years. Fast, opinionated, keyboard-first. For a revenue org, the challenge is the same as Jira: a non-engineering team will not adopt Linear naturally. One tool across sales, marketing, and delivery is the whole point of the Strkr suite.

Spreadsheet plus Trello

The incumbent in most mid-market orgs.

A sprint tracker in Google Sheets, a shared Trello board, a Slack channel for standup updates, and a Google Doc for retrospectives. Works for a quarter. Breaks when the team is 15 people and the work spans three functions. The cleanup cost (dead cards, orphan rows, stale docs) is a quiet drag on every ops lead.

Strkr Projects

One surface, every function, shared automation.

Boards, sprints, backlog, roadmap, capacity, dependencies, retrospectives, and automations in one surface. The revenue org, the marketing team, the delivery team, and sales ops all run their agile cadence on the same software. The automation runtime spans the CRM, Marketing, Messaging, and Projects modules, so cross-functional work routes without a middle layer.

The whole Projects module ships on the Projects plan with every agile surface included.

Boards, sprints, backlog, roadmap, capacity, dependencies, automations, and reports with transparent per-seat pricing and no agile-feature paywall.

Start free trial See pricing
Common questions

What buyers ask about this feature.

What is an agile workflow?

An agile workflow is a repeating cycle of planning, delivery, and review that a cross-functional team runs on short iterations (typically one to four weeks). The core elements are a prioritized backlog, a timeboxed sprint with a goal, a visible board that tracks work in flight, a daily standup, and a retrospective at the end to capture what to change for next time. Strkr implements each element as a dedicated surface rather than a configuration of a generic tool. Reps and project managers alike can run the practice without an agile certification or a dedicated scrum master, because the ritual is baked into the product shape.

What are the six steps in an agile methodology?

Most teams describe agile as six repeating steps: (1) concept, where a new unit of work is identified and briefly scoped; (2) inception, where the team breaks the work into stories, estimates them, and prioritizes against the backlog; (3) iteration, where the team commits a subset of stories to a sprint and builds them; (4) release, where the shipped work is deployed, demoed, or launched; (5) production, where the work is operated and measured in the real world; and (6) retirement, where legacy work is deprecated. Strkr's Projects module supports every step: concept and inception on the backlog, iteration on the sprint board, release through the Releases tab, production via Reports (cycle time, lead time), and retirement through Archive on the project settings.

What is the difference between agile and waterfall?

Waterfall is a sequential delivery model where each phase (requirements, design, build, test, deploy) completes before the next begins. Agile is iterative: the team ships a working slice every one to four weeks, learns from it, and feeds the lesson into the next slice. Waterfall is efficient for projects with stable, well-understood requirements. Agile is efficient when requirements evolve during delivery, which is the usual case for revenue, marketing, and software work. Strkr's Projects module is designed for agile but supports waterfall-shaped projects as well: a long-running epic with sequenced stories inside it, no sprint boundary required.

Does Strkr support Scrum, Kanban, or Scrumban?

All three. Scrum is the default shape: fixed-length sprints with a goal, a sprint planning session, and a review at the end. The sprint strip and burndown chart make this flow native. Kanban is a continuous shape: no sprints, work pulled from the backlog as capacity frees up, column WIP limits enforced on the board. Admins turn off the sprint strip and the surface becomes a Kanban board. Scrumban blends the two: sprint cadence for the planning ritual but no hard point commitment and continuous pull during the sprint window. The configuration lives on the project settings rather than requiring a different product.

What is a workflow management system?

A workflow management system is software that defines, executes, and tracks a sequence of steps a team or process follows to complete a unit of work. Strkr is a workflow management system in the broadest sense: the Projects module defines agile workflows (sprint cycles, status transitions, approvals), the Flows runtime defines automation workflows (triggered actions across modules), and the CRM defines sales workflows (stage transitions, lead routing, forecast cadence). The three run on the same event bus, the same permission model, and the same audit log, which means a single workflow can span functions without integration glue.

What are the drawbacks of agile?

Agile's honest drawbacks are: (1) It requires discipline to run, teams that skip grooming or retrospective lose the compound benefit; (2) It is harder to forecast long-term delivery dates for stakeholders used to Gantt-chart deadlines; (3) It can produce "scope-drift" where the backlog becomes a wishlist dumping ground; (4) Non-engineering teams can struggle to adopt the vocabulary (points, velocity, standup). Strkr addresses the first through automation (standup prompts, grooming reminders, retrospective templates), the second through the Roadmap view with epic bars across a timeline, the third through backlog groupings and multi-select bulk-archive, and the fourth through issue-type customization so marketing, sales ops, and CS can run the practice without engineering-specific nomenclature if they prefer.

Related features

Pair this with...

Project Management Kanban Board Workflow Automation Team Collaboration Process Automation No-Code Automation

Try it free. Bring your team next week.

No sales call, no migration consultant, no four-month implementation. Enter your card, get 14 days of the full Pro tier, cancel any time before day 14 with zero charge. Spin up a workspace, import your CSV, and have something useful before lunch.

Start free trial See pricing