11

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:

  1. I can show the simple form with fields without any fancy styling and mark them as done
  2. I can just do client side validation as mark as done but server side is also the option or both
  3. I can also add some jQuery fancy tool tips, hover overs, captcha, colors, labels for the form
  4. 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

Improve this question
1
  • 5
    which "scrum documents"? Commented Aug 8, 2013 at 15:17

6 Answers 6

Reset to default
13

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.

Improve this answer
3
  • 2
    +1 for "As long as the team all know the answer, it is irrelevant what the answer is." Commented Aug 8, 2013 at 8:29
  • Another +1 for "As long as the team all know the answer, it is irrelevant what the answer is." Documenting requirements with User Stories and breaking those down into Tasks is an art not a science. Each team (including the Product Owner) needs to learn together what level of detail to document in the Definition of Done, in the conditions of acceptance of a User Story or as individual Tasks. Commented Aug 12, 2013 at 12:06
  • You'll be delighted to know that the latest version of the Scrum Guide (July 2013) no longer refers to shippable The phrase now used is potentially releasable. Commented Mar 17, 2014 at 13:43
5

If the cosmetic features are part of the feature, they should probably be done as part of the story. The point is, once you say a story is done, you shouldn't have to do any more coding on a particular feature. Though, ultimately this is decided by the product owner -- they may want the cosmetic features or they may not. This should be spelled out in the acceptance criteria.

That doesn't necessarily mean it's ready for the end user to use, it just means it's ready for someone. That someone could be a tester, or another team such as the back-end team.

If you are asking this as a developer, the answer becomes "you know, because the product owner will tell you whether they want the cosmetic features or not".

If you are asking this as a product owner, you simply have to decide whether you want to break the feature down into more than one story. There is no requirement, other than it must satisfy you, as a means to satisfy your customer.

Remember: the goal isn't to adhere strictly to scrum. The goal is to deliver high quality software to the end user. Use that as a guide when struggling with questions like this. Will adding the cosmetics in the same story as the purely functional parts help you to deliver quality code to your customer? Or, will breaking that into two stories help? Either the answer is clear, or it doesn't matter and you can do whatever works for your team.

Improve this answer
3
+25

"Potentially shippable" means shipp-able not necessarily something that you ship. For example:

A web registration form that looks terrible and has no validation on the fields, may be ok for some situations, like a school project, but in a multimillion dollar business, would damage the brand to show to end users. The code might be shippable without being something you would want to ship or that marketing or legal would let you ship.

It is something that the programmers (and other people that are in the process at this point e.g. designers) would be happy to release as it is right now, even if, for some reason, it would never actually be released like that (e.g. it needs to be translated into other languages before it can be shipped to anyone - Canada has strict rules about the Government buying software that gives equal consideration to French as well as English).

This is a quality check point, you look everyone in the eye and ask if they would be happy to ship it as it is right now, with no extra work, no checking to see if they did that one last thing. I have hear this called the aeroplane engineer check point. You look a engineer in the eye and ask them if they are willing to accompany you on the test flight.

The idea is to be as Agile as possible. The quicker you can get something out to real users; whether that is beta copies of the code to select individuals or A/B testing on your website, the better. If you show users code that is too rough, rough as defined by their expectations for your product, then they will give you useless feedback. They will talk about things that you are not looking for information on like: they don't like that the button is yellow or the text box doesn't line up with the labels. If it IS good enough then you can get useful feedback. The quicker you get this feedback the better! You can validate product/market fit, and assumptions you have made about the feature you have tried to build.

Shipping the feature is the least important part of this. Moving the development team along and finishing User Stories is the important thing. Getting to the point where you can claim something is done is a great motivator.

Improve this answer
1

In my understanding, each story should be "done-able" and "shippable" to the extent that it's ready for consumption by someone, not necessarily the end-user. So, your story may deliver some functionality that can then be delivered to the product owner, who can choose to have it released to end-users or to iterate over the feature again.

That said, you're not precluded from including styling in the "As an end-user, I will be able to register" story. On our team, we try to make every story as small as possible to maintain higher predictability and better ensure we're able to deliver what we promise. If we have a design ready up-front and think it's trivial to apply, it's included in the story. If we think there may be some iteration on the design, that's a separate story -- possibly multiple.

Improve this answer
1

Besides the other great answers to this question, you can also think of the cosmetic features as the variable scope part of the scope-resources-time triangle. Make sure you fulfill the basic requirements of that story, and add the pretty stuff if you have time.

Scrum isn't supposed to guarantee delivery of certain features in a given time. It's supposed to give you the maximum useful work that's possible in a given time. If "optional" cosmetic features don't get done during that sprint, it should be because they weren't possible.

Improve this answer
4
  • In my organization the "cosmetic" features are mandatory before release. We want our application to have a professional and sleek view. What I am wondering is whether we should work to apply the cosmetic stuff with the development of the feature, or at the final Sprints of the project. In the latter case we won't have a potentially shippable product, while in the former case we might waste time on beautifying a feature that we'll decide to significantly change or even drop later. Commented Mar 17, 2014 at 14:01
  • All right, that's an interesting constraint. It sounds like either way could work for you, but the latter case supports the Agile value of "minimizing the amount of work done." In other words, YAGNI is your friend. Commented Mar 17, 2014 at 14:45
  • @Eugene: If the Product Owners wants all features to be delivered in their final sleek look, then that is what you have to deliver. Otherwise, it it up to the Product Owner to introduce additional stories along the lines of "Make X look good". Commented Mar 19, 2014 at 13:56
  • I'm actually saying that my "definition of done" is flexible. It (implicitly) includes something like "The user interface must be clean and professional at a minimum, but it can include extra shiny parts if there is time to make them." That's intentionally giving the developers a lot of wiggle room. Commented Mar 19, 2014 at 14:18
0

It's dependent upon the person setting the requirements, the "product owner." As a programmer, I might be content with an unstyled "registration form" page which simply proves that the business logic in my web services works correctly, and that registering allows you to be authenticated against other resources in the system. In fact, "potentially shippable," since it doesn't necessarily imply that we're literally going to ship it to a client, could allow this to be the outcome of the first user story on the topic, particularly if the technical team and design team are separate resources with separate backlogs.

On a more mature project, you might ship a "developer-designed" version of the feature, with minimal styling, to a pilot or beta client, but revisit the same feature for both functionality modifications (based upon feedback) and design completion.

The purpose of Agile methodology is to allow your requirements to drive the software development process, rather than the opposite. Don't fall into the trap of assuming that one description of the methodology is the True and Only Orthodox Requirement. Easier said than done, of course, particularly if you're in a large organization where Scrum has become an excuse for imposing chaos on the development team.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.