Scrum - where do you do all the 'other' stuff?

Question

With Scrum, there is the principal of user stories and these stemming tasks etc etc iterating around to a finished product - which is fine.

But, let's say I have 100 features that need implementing, in the real world I can't put any developer on these until a lot of the normal ancillary stuff has been done - for instance, doing a UI design (surely you need to have an overall idea of functionality for this?), or building the underlying stuff that doesn't necessarily manifest itself as a feature.

So, where does this happen?

Answer 1

My understanding is that in scrum you only build what is required to implement each user story. Therefore, you build the underlying stuff that is not a feature only when it is required to implement a feature for the user story you are working on.

Answer 2

In my opinion, the best is to include as "Story" the most things that are possible, so everyone has a good visibility of what the time is applied to.

However, there will always be unplanned tasks that have to be done (for example, reinstalling your machine if it is broken). For that tasks, one option is to leave in each iteration some percent of free time, if you have a velocity of 300 story points per iteration, for example, just full 250 with stories at first, to leave place to unplanned things, Then, in the following iterations you can adjust these values according to your past history.

Answer 3

Basically, it happens within each feature, which is easier said than done but is perhaps the whole point of agile incremental software development.

For example, instead of building lots of 'underlying stuff that doesn't necessarily manifest itself as a feature', you should suspect that you Ain't Gonna Need It, and only build as much as you need for the feature in question.

Answer 4

Non-functional tasks can still go on the product backlog, in my view - when I was using Scrum we certainly did that. We had to explain to the product owner why they should be viewed as important, so we could get the time to do them. If the product owner doesn't believe they're very important, they don't get done - and the owner has to live with the results. After being bitten a few times by dismissing your requests for things like load testing and then it falling over, they're likely to come round :)

On the other hand, you may find that there are some non-functional requirements which you originally believe are important, but can languish with no impact. Sometimes, just sometimes, developers' instincts are wrong :)

For tasks which are genuinely gating factors, I think you've just got to be honest with the product owner and insist that you have to do them. If you can't get on with the product owner to the extent required to continue with the project, there are bigger problems than not getting a UI design :)

Answer 5

I would build the ancillary tasks into the first feature that requires it.

It is important to distinguish the difference between the product backlog and the sprint backlog. The product backlog contains user stories that represent "what/why", not "how". When a story is selected for a sprint, the story is then broken down into the tasks required to build it. E.g.: "UI Design" would be a task for the "Select items to purchase" story. There's no harm at the sprint planning level for tasks to have dependencies either; in fact, most of the time there will be tasks that make life easier for other product backlog items.

Hope that helps!