Specifications in spreadsheets vs. stories in JIRA

Question

I think this is a very common issue a lot of companies fight with. So I would like to ask for your input.

Product Owners often prefer to keep specifications in Google spreadsheet. And then write user stories in JIRA (or any other tool) that link to said spreadsheet. Especially when things get complicated. But this often gets out of hand and suddenly you have a lot of different places to check as a developer to make sure you fulfilled the acceptance criteria.

From a developer perspective there are a couple of things that speak against spreadsheets:

• No transparent versioning. You have to navigate past, present and future with color codes or in different sub-sections
• Not all the information is present in the story, so you need to first collect information before you can start to work on a story.
• They aren’t designed to store files, annotations, conversations, and related information that are essential parts of project communication and collaboration.
• When doing the sprint review, it is great to have all the acceptance criteria right in the story in order to efficiently check if something can be considered as "done".

From a Product Owner perspective spreadsheets make a lot of sense:

• All the specifications are in one place and not scattered along multiple stories.
• You can create the data structure most fitting for your needs. You can define columns, add multiple sheets to your workbook, etc.
• You don't have to repeat yourself whenever you write a story. Just reference the spreadsheet.

I am currently moderating between a Product Owner who loves spreadsheets and a Development Team who despises them. I am a developer myself and dislike them, but I see the points the PO makes.

So I guess my questions are:

• Are spreadsheets necessarily bad?
• Are there tools or best practices out there that I am missing?

Answer 1

TLDR: It's the Product Owner (PO)'s responsibility to communicate the needs for the product to the Development Team in a format that they can use.

---

I'll address your provided Pros for spreadsheets:

All the specifications are in one place and not scattered along multiple stories.

It's simple enough to make a filter in JIRA that will give you a report of the Issues you want. You can even export it to Excel!

You can create the data structure most fitting for your needs. You can define columns, add multiple sheets to your workbook, etc.

You can, to a point, do this in JIRA as well - most such needs could be taken care of via features such as custom field or quick filters. While it is possible there may be some needs the PO has that are truly impossible, I think it more likely that s/he simply needs to learn how to use JIRA to fulfill them, instead.

You don't have to repeat yourself whenever you write a story. Just reference the spreadsheet.

There's another way to not repeat yourself: Don't use spreadsheets. Therefore, this argument isn't really convincing - 'ditch JIRA' and 'ditch spreadsheets' are equally valid solutions to this one particular issue - so I wouldn't consider this a Pro for spreadsheets.

I suspect it would be simpler to just keep them in one place, though.

---

Ultimately, though, the most important part I see is:

Not all the information is present in the story, so you need to first collect information before you can start to work on a story.

This shows that the PO is failing in his/her role. The information must be made available to the Dev Team in a form the Dev Team can parse. An Excel sheet is simply not sufficient for most developer workflows.

If the PO wants to keep using spreadsheets, fine, let him/her. But s/he must ensure every single little piece of information within those spreadsheets are replicated to JIRA at all times.

---

Now, that being said, just telling the PO 'you're wrong, deal with it' is not the way to go. I mention above that the PO has to learn how to use JIRA more effectively. Why don't you (or another developer - perhaps the loudest one involving this issue?) first learn how yourself, and then teach the PO?

Much of what seems 'intuitive' is simply familiarity. Once s/he understands and has gotten used to using JIRA, I suspect much of the preference for Excel will fade. For now, though, in the face of any unfamiliar technology, a common response is 'this is unusual, unexpected, and I don't like it. Because it's not like Excel.'

Answer 2

TL;DR

Spreadsheets are great for capturing data. User stories and kanban boards are great for visualizing work or providing conversation placeholders. They can exist together.

The real issue is that both can be misused. Neither spreadsheets nor index cards are "features" or "collaboration," so don't treat them that way. Instead, treat them as process tools that support ongoing communication and collaboration.

Patterns and Anti-Patterns

There seem to be a number of misconceptions about Product Backlog Items and the user story format. Let's address those first, and then see if your tooling question remains a concern.

1. User stories are not specifications.

   A user story is a placeholder for communicating about a backlog item. It is not intended to be a complete specification, take the place of communication with the Product Owner or end user, or contain the entire Definition of Done.

2. The Product Backlog belongs to the Product Owner, but the Sprint Backlog belongs to the Development Team.

   If you aren't placing in-progress user stories and tasks into the Sprint Backlog, then You're Doing Scrum Wrong™. The Product Owner shouldn't be making changes directly to items on the Sprint Backlog; in-Sprint changes should be discussed with the whole Scrum Team and managed by the Development Team. So, revision control of Sprint Backlog stories isn't really necessary for a healthy framework implementation.

3. Change tracking or change requests are an agile anti-pattern.

   Because agile frameworks embrace change, the notion of versioning or tracking deltas between backlog items is a definite anti-pattern. The Product Owner can make any changes they like to items on the Product Backlog before they enter the Sprint Backlog. Once they are part of the Sprint Plan, no changes to scope or backlog content that endanger the Sprint Goal should be allowed without serious consideration of early termination of the Sprint.

4. Standard acceptance criteria do not belong in user stories.

   The Definition of Done is a living policy or standards document that is implicitly part of every story. You shouldn't be writing acceptance criteria for each story; that's an indication that you need to review and revise your Definition of Done.

   Furthermore, acceptance criteria really ought to be required by the Definition of Done. They are usually best implemented as executable tests that the team defines during TDD or BDD development, and should reflect the goal of the user story rather than specific implementation-level details. User stories should define the features and functionality desired by the value consumers, not the underlying implementation details.

   Any acceptance criteria should be captured as testable elements (e.g. Cucumber scenarios) during Spring Planning or very early in the development cycle, rather than left to an external process at the end. Acceptance testing should be integrated into the Sprint, not treated as a post-hoc process.

5. If the team has too much work to track progress without extensive notes, annotations, and cross-references, there's a problem with the framework implementation.

   An agile team is supposed to be small enough to keep communication and collaboration efficient. In addition, agile frameworks minimize task switching.

   In software, implementation details should be captured in TDD specifications, code comments, and BDD scenarios, so there should be a minimum of note-taking and cross-referencing going on. In other words, the work should be self-documenting to the greatest extent possible.

   Additionally, the team should be collaborating and swarming over stories. Work that needs to be meticulously documented, annotated, logged, and updated is generally a whiffy smell that the team is falling prey to the 100% utilization fallacy. By not pairing, swarming, and collaborating, the team misses out on many of the benefits of agile frameworks, including knowledge transfer and the creation of T-shaped teams and processes.

   Don't treat stories and tasks as individual work items to be tossed over the wall between people or teams; work them as a team to get the full benefit of agility.

If you address these issues of principle, you may suddenly find that how you track your Product and Sprint Backlogs becomes a non-issue for the Scrum Team. Even if you don't eliminate the problem altogether, taking these core principles into account will definitely help improve your overall process and allow the team to consider how they can best adapt the process (and any tools that support the process) to best effect.