Scrum - where do you do everything else?

Question

With Scrum there is a principle of user history, as well as these tasks, etc. iterating around the finished product is normal.

But, let's say, I have 100 functions that need to be implemented, in the real world I can not impose a single developer on them until a lot of the usual supporting material is done - for example, to create a user interface (of course, you need to have a common an idea of ​​functionality for this?) or create basic material that does not necessarily manifest as a function.

So where is this going?

Answer 1

I understand that in scrum you only create what is required to implement each user story. Therefore, you create the base material, which is not a function, only when you want to implement a function for the user story that you are working on.

Answer 2

Non-functional tasks can still remain behind the product, in my opinion - when I used Scrum, we definitely did it. We had to explain to the product owner why they should be considered important, so we could spend time on them. If the owner of the product does not consider that they are very important, they cannot cope - and the owner must live with the results. After a few bites, rejecting your requests for things like stress testing and then it crashes, they will probably come :)

On the other hand, you may find that there are some non-functional requirements that you initially consider important, but can languish without any impact. Sometimes, sometimes, the instincts of the developers are wrong :)

For tasks that are really line factors, I think you just have to be honest with the product owner and insist that you have to fulfill them. If you can’t contact the owner of the product in the amount necessary to continue the project, there are big problems than the lack of user interface design :)

Answer 3

I would build helper tasks into a first function that requires this.

It is important to distinguish between the gap between the product and the gap between the sprint. The backlog of the product contains user stories that represent “what / why,” not “how.” When a storyline is selected for sprinting, the story is then broken down into tasks necessary to create it. For example: “User Interface Design” will be the task for the “Choose Items to Buy” story. There is no harm at the level of sprint planning so that tasks have dependencies; in fact, in most cases there will be tasks that make life easier for other elements of the procurement of the product.

Hope this helps!

Answer 4

Basically, this happens in every function, which is easier said than done, but perhaps this is just the goal of flexible incremental software development.

For example, instead of creating a lot of “basic things that don't necessarily appear as a function”, you should suspect that you will not need this, and create as many as you need for this function in the question.

Answer 5

In my opinion, it is best to include in the "History" everything that is possible, so everyone has a good visibility of what time applies to.

However, unplanned tasks will always be performed (for example, reinstalling your machine if it is broken). For these tasks, one option is to leave a certain percentage of free time at each iteration, if you have a speed of 300 plot points per iteration, for example, a total of 250 stories with stories at first to leave room for unplanned things. Then, in the following iterations, you can adjust these values ​​according to your past history.