2

I'm trying to figure out a way to split user stories in a way that we can incrementally create value upon completing them at the end of the Sprint. I'm using Mike Cohn's book, User Stories Applied as a guide. The platform I'm building has a lot of back and forth between the tasks for the end user and the site administrator actors. This makes it very tempting to split a story on technical boundaries like so:

As a Site Administrator, I should be able to configure the main category banner text and image

As a User, I should be able to view the banner image and text in my language on all devices

Although this seems to be a reasonable breakdown, it introduces dependencies between the tasks for the entire story to be complete. This might lead to the possibility of partially completed stories at the end of the Sprint - without a tangible value add. One possibility is consolidating the story into a single one and adding both of the above as subtasks for the story.

As a ???, I should be able to configure banner text and image

As you can see, this does not feel intuitive. Do you feel that there is a better way to approach the problem?

  • 1
    RE: "This might lead to the possibility of partially completed stories at the end of the Sprint - without a tangible value add." Technique such as feature flag will allow you to ship partially completed work and manage increment better. See: martinfowler.com/articles/feature-toggles.html – yclian Jul 2 '17 at 15:42
2

Any time I see "and" in a requirement, warning bells go off. Consider splitting your requirements along that point:

As a Site Administrator, I should be able to configure the main category banner text

As a Site Administrator, I should be able to configure the main category image

As a User, I should be able to view the banner image on all devices

As a User, I should be able to view the text on all devices

These are four independently testable and independently deliverable user stories. Of course, viewing the set image and text may not be as useful if it is a static value rather than something that can be configured. But you can still design it as if it was configurable (eg reading from a configuration file or database rather than hard coding it) and just not having the ability to configure it.

  • Thanks Thomas - I see where you're coming from. I feel the problem with splitting stories in such level of granularity is that it might lead to rework if linked stories are not taken up in the same sprint. Sure, a developer can assume that the configured properties will eventually arrive from the admin end, but his assumptions can only be tested once the linked item is done. The backlog can become a mess to maintain with detail oriented stories - specially when just adding a field is not significant go merit it's own story. Thoughts? – Karthik Iyengar Jun 28 '17 at 14:53
  • @KarthikIyengar You don't need to take them up in the same sprint. However, you should probably do just enough up-front design work across all of the stories to understand how they all work together. If you're using a ticket tracking tool, you should probably link the stories together appropriately so that way the development team knows that there are related things and can include considerations for them in their work. None of that requires delivering the stories as a unit, though. – Thomas Owens Jun 28 '17 at 15:05
2

Stories should not be concerned about implementation. You're missing a key part. What you should be aiming for is:

As a ???, I need to ???so that I can ???.

Why does your site admin want to allow this? 'Because his boss told him to' is not a good reason to put into a Story - why does the boss want it? 'Because customer X needs it for Y so that they can Z.' In that case, the story should be 'As X, I need to Y, so that Z.'

While X could be a site admin, in those cases Y and Z should typically be things customers don't care about - such as preventing customers being unable to see private company information.

'I require to write this bit of code' is not a requirement, it's an implementation detail. 'I require my program to remind me what my name is on Tuesdays, because Mondays are so awful I often forget what it is' is.

Once you remove any implementation details from Stories, it should become more obvious how you can split them into minimum-sized, value-providing increments.

  • I thought about my story again in terms of your comments. I arrived at As a site admin, I need to be able to configure the banner so that users can see it prominently on the home page. The details of how to get this done can then be discussed in the sprint planning, causing the subtasks (create a configurable backend, create UI where banner will be seen) become tasks to reach that end. Does this capture the essence of what you wanted to convey? – Karthik Iyengar Jun 28 '17 at 14:59
  • Building on this: introducing a feature should make someone capable of something they weren't before. It sounds like the capability you're describing is more business-focused and on the admin side; the user being able to see it is secondary. What happens if you tell it in prose? "Our site admins need to test effects of X on conversion rate," and they way you decide to implement that is to make X configurable by admins in such a way that it impacts the user experience also. – yitznewton Jun 28 '17 at 15:31
  • "introducing a feature should make someone capable of something they weren't before" - this, exactly. Ask yourself why your Site Admins want the banner seen by users on the home page. What would doing that accomplish? – Sarov Jun 28 '17 at 16:46
2

This is a common confusion and only solution is identifying different perspectives.

From your question, I feel you are visualising

"adding content in the backend which ultimately displays in the frontend"

as one single story which can either be broken down into

"1. one story-two interdependent tasks"

or

"2. two interdependent stories"

both of the above unable to deliver anything useful if not complete in the same sprint.

Look at it this way...

There are two users involved - site admin and User(or visitor) - so it can not be a single story. It can only be a "feature".

Also, though the "feature" may not be complete, for respective users the functionality can be complete.

Look at it this way...

As a user, I don't care if the content I am seeing is hardcoded in a template, or there is a form in the backend to configure it. If I see the content in any device of my choice, the story is complete for me.

As a content author, I just need a convenient way to add/modify the content. Once I add the content, I am assuming that programmers have done their bit to display this content in proper formatting. It is not my job to do the CSS. If formatting is not appropriate, PO will thrash the developer but not me, so my story is complete.

Now which story should take preference?

Think...

Will the banner content be updated often? If no, should I just add the content in the template and prioritise the backend configuration for the banner? If yes, should I demo by end of this sprint how the backend system for the site admin look like and take up the display in next sprint? Or priority for the client(read business) is to know that their visitors can see the content in any device - I should tell them that we have made the display adaptable to all the devices and will make the content configurable in the next sprint?

Solution?

User stories should never be created on technical boundaries. A good user story always solves a business case - either something that affects the end user directly(like displaying information through the banner), or indirectly(efficient way to update information in the banner).

Scrum is not about waterfall-like rigidity. Features can and they do overlap during early sprints. This will automatically sort as the product matures. If not, either the developers are not making the code modular enough or backlog needs grooming. Any of the case will surface in one of the retros.

Initially it is good to create feature completion projections. Inform the stakeholders by when they can see the complete feature. This will help in creating expectations and consequent sprint planning.

Sometimes it is difficult to isolate features in independent stories due to limitations of the technology platform or business priorities. It is perfectly normal and there is no golden rule to escape it. Until the team is demonstrating improvement after each sprint, you are on the right track.

TL;DR It is important to grasp AGILE as continuously evolving product-first ideology and not another way of project management that is trending in the market.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.