I was reading the Scrum documents and it says that the tasks in Sprint should be

Question

I was reading the Scrum documents and it says that the tasks in Sprint should be "potentially shippable".

I am confused by what this means. Suppose in Sprint 1 the goal was, "user registration form".

How much detail do I need to add for something to be ready to ship? For example:

I can show the simple form with fields without any fancy styling and mark them as done

I can just do client side validation as mark as done but server side is also the option or both

I can also add some jQuery fancy tool tips, hover overs, captcha, colors, labels for the form

Then there is whole lot of styling about how to show error messages on screen

I can do endlessly on one topic. So how do we divide that and when I can think of that as shipping ready.

Or do I need to write each smallest possible thing like showing errors, popup or light box text as subtasks and put them as sprint. This would lead to 1000s of tasks for whole project.

I mean then again if some work for Internet Explorer and some for Firefox then again do I need to divide those as tasks as well. Time has to be spent on them and when manager asks me what you did in that time, I won't have any tasks to tell but in reality they all are part of User registration

Explanation / Answer

Agree this with the product owner and the Scrum team, not the internet. This should be determined in your Definition of Done, and will be largely dependent on how the team works.

Although the feature should be 'shippable' (I hate this term in Scrum) it could be argued that the functionality is shippable without the UI. Many people suffer this misconception in Scrum - the aim of a sprint is to get as many stories as possible (ideally all) 'Done', but it most definitely does not need to be built into something that could be released.

It is important to iron things like this out early, so everyone across the team is working to a common goal. The ethos of Scrum is communication, so ask the Scrum team and draw a logical conclusion.

You may work in a team where UI is generally handled separately, for example by a different team or once UI experts decide how the form should look etc. Alternatively, in a small project/team it may be expected that the UI is built as you go.

As long as the team all know the answer, it is irrelevant what the answer is.

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.