Splitting user stories

Question

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?

Answer 1

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.

Answer 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.

Answer 3

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.