How to make user stories independent in multi-discipline teams

Question

When there is a team which has multiple disciplines such as designers, artists and programmers. How should user stories be written to make them independent?

Example: "As a user, I want a beautiful and an easy to use UI for searching results"

That story requires design to make the UI easy to use and it requires artists to make it beautiful. But also it has to be programmed to actually work.

It can't be done one after another. If an artist concepts the UI by herself, it might not be as usable as the UI designer wanted. And it might not be even implementable by the programmer.

So far it has been done by sub-tasking the story to feature all these disciplines and what each discipline needs to do before it is done. But it is easily left hanging if one discipline is blocked from completing it e.g getting ill.

If making stories independent is not possible, how should multi-discipline stories be handled?

Answer 1

Multi-disciplinary teams need to be collaborative

There simply is no way around this. Teams cannot do their individual work inside a vacuum. Also, user stories should describe features, and should be developed in vertical slices, not horizontal: e.g., your UI designer should not complete the UI design before discussing the designs with UX, web developers, and your DBA's. Multi-disciplinary teams need to be working together constantly to ensure the right product is being built (and the right product is being built correctly), furthermore, each team member should value and understand what feedback loops are and why they are important.

Your original approach to breaking out the work is correct

I believe you have the right approach and I have seen many successful teams do it this way. Although your approach is correct, I believe you need to re-focus your user stories on the features/functionality that is important to the user as opposed to referencing a degree of quality. I feel that quality is something the Product Owner and team should be addressing with Acceptance Tests as well as input that could be gathered from additional functions such as a user-feedback session.

Importance of Daily Scrums and Following the 3 Questions

It sounds like your team has trouble communicating and one discpline area is held up by another discipline area that causes the original work to become stagnant. If this is the case then the Scrum Master needs to be asking these questions on a daily basis, forcing this information out of the team, and working to facilitate discussions regarding these stories early and as often as possible in order to ensure that the team is properly collaborating and that blockers are being addressed.

Reiterate the importance of Feedback Loops

Scrum is a very simple process to follow, and at its core, it is simply an extrapolation of the Scientific Method. I think it's very important for every team member to understand this and to approach work with the idea that they need to apply this method, share their work, analyze their results, and update their approaches based on the feedback they receive with shorter cycle times being the most preferable.

Answer 2

In general it is recommended to base User Stories on the user's functional problems. Having a beautiful design (whatever that means ;) ) is actually a non-functional requirement (in that case Usability) and is represented as a constraint that is attached to the User Story.

Whole User Story

Furthermore in an ideal case User Stories are layer independent, meaning they are not solely based on the frontend or backend, but represent a whole feature (going through all architectural layers). If you have features/User Stories that are too big, you do not seperate them by architectural layer, but using other criteria. There are various techniques depending on the User Story (compound vs complex), take a look at User Stories Applied. Another possibility, which I highly recommend, is User Story Mapping by Jeff Patton.

Design Spike

If you need time to explore the UI and UX you could introduce something like Design Spikes which are used one or several sprints before the User Story is going to be implemented. Generally Spikes are used for functional or technical exploration, but this concept could also work for design.

UI - UX Prototpyes

Another approach is described by Marty Cagan in his book Inspired. Summarized, you actually build bigger prototypes for new features and explore UI and UX concerns together with users. This created protoype is than used as a requirements base and guides the actual implementation. Additionall you could find some inspiration from Lean UX to restructure your UI & UX process.

Answer 3

Teams should be, by definition, cross functional, and so in a way, most stories are multi-discipline. In your example, I would imagine the developer, designer, and UX expert sitting down and brainstorming what they need from each other with a whiteboard for a little bit, then agreeing, perhaps, that the developer will return a set of results that will each have a title, URL, and brief description. Now the developer can code up the business logic and data layer interactions while the designer works on the CSS. Yes, it's true that if one of them doesn't do their part, the story isn't complete. That's fine because without both sides of that, you can't release the functionality to the customer, so it's not ready to be called done.

Where you may be encountering difficulty is if the UX expert is concerned about expanded functionality, like expanding the search for more results or inline results as you type your search terms. This is where you'd want to split the story so the basic search is complete and releasable, then you build on the functionality to make it more sophisticated.

Answer 4

Having a team made up of specialists is very difficult to manage.

One approach is to try and spread the knowledge around, so that, for example, the UI's might do a bit of design and the designers might do a bit of UI. I have worked with teams that do this and although the output of individuals is reduced, the output of the team is actually increased.

Another approach is to only take work in to the sprints that is constrained by the most bottle-necked discipline. Although this is far from ideal it does highlight where there is an inbalance in the makeup of the team. As an example, you could demonstrate that there are not enough back-end developers and as a result the UI and designers are unable to fill their time.

Try to utilise the task board to optimise the throughput of stories. For example, you could have columns that represent 'in design', 'UI' and 'dev'. Use the daily stand-up to look out for potential bottle-necks and to determine which stories should be started next to best even out the spread of work across the disciplines.