6

We know by books that: User stories should be Valuable, estimable, independend and so on...

We are newbies on all this SCRUM stuff, and we have arrive to the following feature / epic / backlog item:

"Accept reservations by SMS"

The problem is that, none of us knows nothing about SMS sending and receiving services at the moment.

We can split this into small user stories, and split it into:

As a Restaurant Owner, I wish to receive my website reservations by SMS on my phone, so that I can prepare the table for my customers.

And also:

As a restaurant site visitor, I wish to make a reservation so that I can be assured that I will have a table once I arrive on the restaurant.

But on both user stories, we still have a huge ??? factor.

Because we need to investigate HOW and WHAT are the technically features, before we can split those User Stories into something "Small, Valuable, Estimable, and so on..."

How can we deal with this?

We are thinking about creating on those USER STORIES, a TASK for "Investigate further". What say you?

Improve this question
1

3 Answers 3

Reset to default
5

Check out this article from Scrum Alliance: Spikes and the Effort to Grief Ratio

Basically the idea is to use add a new item to the backlog, a time-boxed research spike, that will allow you to investigate the matter further. The value delivered at the sprint review is what you learned from the spike.

Improve this answer
1
  • Scrum alliance deleted all user submitted articles. Archived version of the article can be found here
    – Geoff Burns
    Jun 17, 2020 at 7:39
4

Spikes

Often teams come across requirements that require a new set of components the team is unfamiliar with, for example your team may never have worked with an SMS gateway and now need to build tools. Quite rightly the team have no idea what it will entail.

The first is to be very transparent to the PO, that the team does no know how to do this and needs a bit of time to investigate it. We call this investigation, research a spike.

There are rules around spikes

  • They are time-boxed as to prevent the spike going on forever.
  • They should have a goal and deliverable; e.g. deliver a Proof-of-concept to send a SMS message.
  • At the end of the spike, the team should review whether it was achieved.
  • The result of the spike should be used to clarify an enhance the product backlog where the original uncertainty was raised.

Personally, I do exactly what you are suggesting. I have a Story with a single task as a spike. The amount of hours assigned to the task is fixed/time-boxed. I have a second task, which is to groom the product backlog and remove break the ambiguous XXXL story down into many finer stores.

Improve this answer
0
1

Stories Should be Actionable

When you talk about the granularity of user stories (as opposed to themes and epics), the stories should be actionable. If the action item or tasks necessary to complete a story are not self-evident, then your story is insufficiently granular and needs to be decomposed further.

For example, when you say:

As a Restaurant Owner,
I wish to receive my website reservations by SMS on my phone,
so that I can prepare the table for my customers.

your team may still have a large cone of uncertainty around the implied components of this story, such as:

  • How is a reservation represented?
  • How is a reservation stored?
  • How is a reservation retrieved?
  • How is phone information stored?
  • How is phone information retrieved?
  • How is a reservation transmitted to a phone via an SMS gateway?
  • How will you test this story?

This story might be fine if these issues are already well-understood by the team and clearly defined elsewhere in the project—but if that were the case, you wouldn't be asking about how to split the story further. So, it certainly seems likely that you need to address these sub-stories as part of an over-arching SMS theme.

Improve this answer
3
  • I understand your point of view. I can well divide the stories on even further more stories. But two questions arrive: 1) if we take, for example, your point number 2 "how is a reservation stored" that user story will take into consideration what "user"? It doesn't seem clear what user are we referring to on some of those sub stories and that could be an issue. Do you see my point? Another question is 2) Even if we found the "user" and the story is written, since we don't know nothing about the answer to that question, even if, very specific, we will still have a XXL user story.
    – MEM
    Jul 24, 2013 at 15:52
  • 1
    @MEM 1) The bullets are just suggestions. It's your project; you need to figure out what the story means to your team. 2) A fully decomposed story will allow you to create an finite time-box for story spikes. Whether through decomposition or story spikes, you need to reduce your cone of uncertainty.
    – Todd A. Jacobs ♦
    Jul 24, 2013 at 17:55
  • So, instead of one spike, we may talk about several spikes related to that epic or, perhaps (not sure if you agree here), one spike with an acceptance criteria quite clear about all those points we may have).
    – MEM
    Jul 25, 2013 at 15:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.