Is defining business rules the same thing as a story spike in Agile?

Question

I am a developer in a new job where the team uses Agile. This is the first time I've been in a fully Agile team and I'm feeling a bit lost.

I've been asked to do a spike for the next block of work but after doing what I thought was expected of me, I've now been told that what is required is the business rules, because the goal is clear but the details haven't been worked out yet.

I've looked for information on what a spike is, and business rules don't seem to fit into it, being either technical or functional, which seems like the business rules should be mostly worked out by then.

What seems to be required is solution architecture. Do I understand this correctly or do I have a misunderstanding?

Answer 1

TL;DR

You likely have an X/Y problem. You haven't articulated what the central user story is, or what the goal of your story spike is supposed to be. In such cases, you should halt the line until you gain clarity on the actual objectives from the Product Owner.

Story Spike Defined

In Scrum, a story spike is just a time-boxed learning experiment where the team does research or a small-scale proof of concept in order to accurately estimate some other piece of work.

As an example, given a story that is large or complex like:

As a widget customer
I want an assembled machine that consists of 100 widgets
so that I can display it on my desk.

you might not know how much time or effort that will take. You might decide that you'll create a scaled-down user story for this Sprint so that you'll have some lessons learned to aid your estimation of the "real" user story next Sprint.

Your story spike for learning about the "real" story above might look like the following:

As a widget engineer
I want to assemble five widgets
so that I can generate an estimate for assembling 100 widgets.

Other Solutions

Depending on what the real problem is, you might find that you need to consider alternative solutions. Some examples include:

• Not accepting poor-quality user stories into the Sprint in the first place. Good user stories should follow the INVEST mnemonic. The success criteria should be well-understood and measurable before the story is accepted into the Sprint by the Development Team.
• Reworking the story with the Product Owner during Backlog Refinement or Sprint Planning until the objectives are clear to everyone.
• Creating a separate business analysis or requirements-gathering user story as a prerequisite to this one, or rolling this work into your estimate or Definition of Done for the story.
• Treating user stories as conversation placeholders instead of as specification documents. Good user stories describe what is needed, not how it will be implemented.

In short, the X in your X/Y problem is most likely improper use of user stories or poorly-defined requirements. Even if the problem is something else, communication is the missing ingredient in correctly identifying the problem and working towards an effective solution.

Answer 2

In Scrum the Product Owner provides the requirements and the development team works on delivery.

The Product Owner provides requirements in the form of a backlog and the delivery team then estimates how much they can fit in the next sprint and then works out how to deliver the requirements.

Sometimes the delivery team finds that it is struggling to provide an estimate for a requirement, or they may be struggling with the technical details of delivery. When this happens, the team may decide to do a spike.

The spike has a very specific purpose. It is so that the team can resolve some unknowns, so that they can go back to working normally. That is why spikes are an exception rather than a regular occurance.

Typically the Product Owner will provide business rules as a part of their requirements, or at least will know who to ask to find them out. They may, on occasion, ask for the development team's help with getting the details of a requirement. Scrum is a collaborative approach.

It sounds like in your situation the Product Owner has asked the development team for help with discovering some business rules. This is not all that unusual, particularly with a poorly documented legacy system. The development team have wrapped the discovery in a spike as the information is needed before they can estimate and make a start on the work.