views:

82

answers:

3

If I divide development of a particular feature into multiple stories:

  • First one for a high level design of the feature,
  • Based on first story I create other stories to develop the different stand-alone pieces that compose the feature,

Does it mean I'm doing waterfall?

Furthermore - if I divide development of the previously identified stand-alone pieces into design and implementation.

Would that mean that I'm doing waterfall?

Note: I am big time Scrum novice.

A: 

No, you're not. The sub tasks can be added to the backlog (presumably with roughly equal priority so they come out around the same time) and then the super-task would be to integrate/test/etc the separate components.

It sounds like a valid way to breakdown a large component to me. Just make sure you size up the different chunks appropriately. I've found 4-16 hour chunks work best. Giving 40 hours for a task means they'll do 2 hours of work until Friday when they cram the other 32 in (along with lots of bugs).

glowcoder
That sounds reasonable indeed - thanks.And what if I break (some) of the stand-alone pieces into design and implementation stories? Would that qualify as waterfalling?
finrod
I don't see how it would be waterfalling. Although, I wouldn't get caught up on terminology. "Best-Practices" are whatever gets your development team working efficiently, and your customers happy. So give the task breakups a shot. If it works, it works. If it doesn't, get feedback from your team and your customers (please don't forget the customers... they're the most important part of Scrum!) and find out how the system can be improved.
glowcoder
+1  A: 

Scrum stories tend to be about "business value":

Business value is a concept that describes the relative worth of any development effort to the business. Business value is often unquantifiable, but often relates to money.

You can think of business value as something that could still be sold if the project was stopped.

If you write a story to create: "a high level design of the feature", what you would produce by implementing that story isn't something that the business can sell. It's not something customers can try, buy, use. In effect, the business value of that story is zero.

You might have better luck thinking about stories "vertically". "Vertical slices" are minimal features that cover your entire technology stack. For example: "A user should be able to enter their name in a text box, click a button, and be shown their record in the database." It's not, by itself, especially useful, but it is more valuable than a feature design.

JeffH
+2  A: 

There is no such thing as design and implementation stories, User Stories should provide some level of end-to-end functionality to the user (i.e. delivering customer value).

The fact that you are mixing the terms stories and features doesn't help to communicate but what you're describing sounds actually like tasks (Sprint Backlog level), not user stories (Product Backlog level).

And if they are not tasks, then they are very bad stories. Maybe the "functionality" is too big and you should put the story on diet but what I see here is a typical story smell.

If you are new to User Stories, I strongly recommend to use the regular template (As a <type of user>, I want <some goal> so that <some reason>) and also to follow the INVEST model. This will really help you to avoid pitfalls like the one of your question.

Back to the real question (Am I doing waterfall?): there is nothing wrong with doing so design inside a Sprint (as a task of a story). But if your whole story is about design, you're not really doing Scrum, you are supposed to deliver a demonstrable end-to-end increment at the end of the Sprint.

Pascal Thivent
Ok. So I would groom the backlog to flesh out high-level design for the different user stories and then include those in the Sprint, potentially breaking the user story into Design and Implementation tasks. Would that be a good Scrum practice?
finrod
@finrod: A story is not about design or implementation, it's about adding value to the software. If you comply with that, you're on the right track.
Pascal Thivent