TL;DR
You're letting a tool drive your workflow, and deliberately hiding work rather than making it visible. Both of these are agile anti-patterns. Furthermore, you're not slicing work up in ways that reflect capacity consumed by the Development Team, as opposed to simply tracking external dependencies.
The fix is easy: more transparency, more visibility, and greater collaboration with stakeholders and customers. I detail some of the ways you can achieve this in the sections below.
No Invisible Work, Ever℠
Because this pre-work necessary to deliver value to the customer is something the customer does not care about, pre-work cannot be tracked as user stories!
This is absolutely wrong. Agile frameworks and methodologies heavily rely on:
- visibility,
- transparency, and
- intense customer collaboration.
By hiding "pre-work" or attempting to bury it inside some other attribute of the work, you are actively harming communications and active collaboration with the customer. How can the customer possibly make informed business decisions or trust in the process if, like an iceberg, most of the "real" project is hidden below the surface? Don't do that!
While it's true that most customers won't care about the minutia of product development, it's extremely important that they are able to see "how the sausage gets made." If a feature is difficult to implement, or requires a high level of effort in areas that don't directly deliver value, the stakeholders must see that. When this currently-hidden work is surfaced and visible, stakeholders can make better-informed decisions about what features they value, what resources they can bring to bear, what processes they can improve or impediments they can remove, and whether the cost/benefit or return on investment is still worth it after evaluating the full measure of work involved.
"This is a 40-point story" is not a useful business metric. "This feature will likely take 12 one-week Sprints at an estimated cost of $105,000 in labor to deliver" is a much more useful decision-making tool. Scrum isn't just about completing Product Backlog Items; it's about completing the right user stories, and constantly re-evaluating the process and the prorities!
Tasks are Decomposed User Stories; Sprints Deliver Increments
A consultant suggested we use tasks instead.
Maybe. A task is not a user story, and a user story isn't necessarily a shippable feature. In this specific case, you are allowing your tool to dictate your process. Never do that!
Your process has a whole host of issues, but most of them stem from trying to hide work from your customers. This creates a set of X/Y problems that will lead you to the dark side.
Most customers primarily care about potentially-shippable value, not necessarily features. While a great user story represents a vertical slice of value to the viewpoint character in the story, it may or may not be a shippable increment on its own. Instead, the team should focus on the increment delivered by each Sprint, which is generally captured by a Sprint Goal.
It's worth noting that JIRA is primarily a ticketing tool. It's not "Scrum in a box," so trying to implement Scrum solely through the lens of JIRA is a surefire way to drive your team nuts. JIRA provides no core mechanism for representing a Sprint Goal, or to treat the output of a Sprint as a coherent increment. While you can abuse various features of the tool to simulate those things, the Scrum Team (not the tool) must take responsibility for tracking the right aspects of the framework.
Each Sprint need not result in a formal release. It simply must deliver a potentially-shippable increment of value. There are cases where multiple Sprints are needed to reach an agile release milestone. That's okay! But you can't measure your progress towards that release unless you're tracking all the value-added steps needed to get there. In this case, "value-added" doesn't inherently mean "customer-facing." It simply means work that adds value to the product, and work that is essential to the development of the product adds value, too!
Decompose to Fit the Time Box, and Track Everything
Most product features will have a lot of pre-requisites. When possible, vertical slices that fit within a single Sprint are ideal. That's not always possible. In such cases, you capture the feature as an epic, and then build themes and user stories that will collectively deliver the epic.
In particular, a user story is a coherent bit of product development that:
- Meets INVEST criteria.
- Contributes to the current Sprint goal.
- Fits within a single Sprint.
If you have a story or epic such as "Display data from Faux News" that won't fit into a single Sprint, then you need to decompose the work into measurable increments that do fit, and that work should be visible to both the team and stakeholders.
Maybe the current Sprint Goal is to display stats on every Disney Princess ever filmed. You have some spare capacity in the Sprint, though, so you also take on the story that says:
As corporate counsel,
I want to send over an initial contract to Faux News
so we can get agreement to add them to our portal.
The Development Team might then decompose this into some low-effort tasks. Some examples might be:
- Request the corporate counsel write a contract for Faux News.
- Validate that the contract has been sent to Faux News by the last day of the current Sprint.
- Add a story to the Product Backlog to follow up on the contract status in a future Sprint.
In reality, these sorts of stories are often 0.5 - 2 story points because the level of effort for the Development Team is quite low. They're basically conversations that need to be held, resources to be requested, or tracking activities to be performed. You aren't tracking the lead time or cycle time of the task, but rather the level-of-effort required by the members of the Development Team!
With that in mind, most of the stuff you've defined as "pre-work" definitely belongs on the Product Backlog because it needs to be tracked by stakeholders and by the project. However, I suspect most of the pre-work stories represent dependencies for work the Development Team must do, rather than high-effort work the team must do itself.
As an example, you could redefine a user story like:
# This story is probably wrong unless the Scrum Team
# has a lawyer as a full-time member of the Development Team
# who is actively participating in the Daily Scrum.
As a team,
We need to get a contract from Faux News
so we can integrate it as a data source.
into a more accurate task like:
Email Bob and Susan over in legal about the contracts we expect to need next Sprint to begin working on the Faux News data source.
This turns a misleading and incorrect story about "pre-work" (more accurately, an external dependency over which the team has little control) into a concrete task the team can actually perform. Specifically, the task becomes one of making a request rather than delivering an artifact. This is immensely more measurable, easily estimatable, and simple to track as as done or not-done.
Whether you make each contract request a user story in its own right, or whether you bundle up a bunch of similar tasks into a user story like "request all the current contracts" is up to you and your stakeholders. Finding the right level of granularity is an art, but visibility, transparency, communication, and collaboration are the guiding principles that can help you define the optimum level for your particular project.
