scrum and specifications

Question

So we start Scrum today and start going over story points estimates.

The first story that comes up is a new screen that needs to be developed. It has 1 sentence to describe the screen and 3 user acceptance tests.

This starts a fight between the development team and the product owner.

Product owner says that stories do not need to be speced out and they will just be fleshed out during the sprint.

We say that the story needs to be completely speced out for the sprint.

But now I am starting to be unsure about who is right....

Any good articles on this that I can send to the team about how defined a user story has to be?

Answer 1

What happened during sprint planning?

It appears that you did not review the sprint plan to see the stories in advance of starting the sprint.

That's okay.

Stories are fleshed out during the sprint. That's the point. Relax.

Flesh out the story quickly, build quickly.

At some point, the one sentence story may become rather complex. If that's the case, break it up into something you will finish during the sprint, and stuff you will not finish. It's okay to have some stuff that was not known and did not get built.

Relax.

Do not overspecify everything. Do not specify every nuance of the story before the sprint. Just build something that will work. As quickly as possible. That's why it's called a "sprint".

Don't build everything you imagine. Build enough that the story can be performed by the user.

The point is to build something that works on schedule. If you have to adjust the scope of the story, that's okay.

Answer 2

Any good articles on this that I can send to the team about how defined a user story has to be?

A story is typically made of one sentence based on the following template: In order to <benefits>, as a <role> I want <action> (and I like to add "how to demo" steps that help to understand the story and to build acceptance tests). The idea is to capture the essence, not the details. Details are captured using face to face conversation during the sprint (and may be added as high level notes to the story). But a user story is not a contract, it's a promise for a conversation (about the scenario for which the story is the title). If you need some guidelines, following the INVEST model has worked well for us.

PS: No offense but the development team seems to react very defensively (asking for full speced things sounds like "hey, we did it as it is written", i.e. CYA). A user story leaves some space for creativity. Isn't that nice? If you need more details, take your responsibilities, go gather them. And if for any reason you can't get required clarifications or details, raise an impediment and have your ScrumMaster work on it. Personally, I enjoy having some space for creativity.

Answer 3

IMHO fighting is not good - Product Owner, Scrum Master and Development Team form the Scrum Team so they need to work together. They want to achieve the same thing - building a great product.

To me the question is how important it is for the Product Owner how the end result looks like. If he says: "We hired the best people on the market, you're the experts, whatever you come up with is fine with me as long as the user need is fulfilled", then I'd fine with the PO statement. But of course he can not complain afterwards that he does not like the look or the colors!

Another point is that the team needs to be confident that they can commit to this story. Usually teams estimate story size with planing poker so if the development team can not estimate, you need to invest time before that you can estimate (e.g. talking about the story before, spiking and negotiate with the PO about the story). Sometimes the designer/UX guy needs to work ahead and create mockups for the upcoming user stories.

It's always about finding the balance between planning and doing :-)

fs

Answer 4

I believe Martin Fowler's blog post on Conversational Stories probably answers your question best. You really don't want to be in a situation where the Product Owner is required to spec out everything in detail. You've got a team of smart, creative people that are perfectly capable of making good implementation suggestions as well as asking the right questions as they come up during the sprint. You don't want to lose out on that creativity and input by locking down requirements up front.

The story should be clear enough that the team understands what the feature is and small enough that the team can complete it in one sprint before it is added to the sprint backlog. The rest of the details should be handled via conversations during the sprint.