By Alex Yakyma
In this post we will continue outlining the ways of splitting user stories. Previous post was about splitting stories that include complex or data-intensive algorithms (Splitting User Stories. Part 1: Incremental Development of Complex Algorithms). Post #1 also includes interesting links and provides brief overview of all posts in the series. Currently we will touch another common class of stories – those including much of the UI work.
In this post as well as in the previous one we will stick to the simple model and terminology for splitting: a Story splits into First cut – something simpler and faster-to-implement and then Cut 2 – finishing the rest of the functionality.
In case of rich UI stories Cut 2 may often be translated into non-functional requirements (NFRs). And in this case it has to be sooner or later applied to all the functionality of the system. Let’s consider few examples:
• …Cut 2: Using same page/screen template
• …Cut 2: Using jQuery for AJAX calls
Now we’re approaching the 12 ways of splitting UI stories.
1. Synchronous calls – Asynchronous calls.
Story: As a user I can register in order to make purchase.
Cut 1: …registration is on the separate screen, process totally synchronous.
Cut2: …I can register asynchronously using inline form.
2. Basic controls – Advanced controls.
Simple text boxes instead of advanced calendar control. Screens instead of pop-ups, etc.
3. Basic validation – Complex validation.
Validation sometimes can be really complex and it may be useful to make first step with minimum validation functionality and then add it in the next cuts. Example…
Story: As a user I can register in the system.
Cut 1: …required fields not empty Cut 2: …email fully validated; username to satisfy the pattern and to be unique; zip code validated against DB; Street address validated against pattern; DOB within the range. Field length requirements checked on client side.
4. Functional UI – UI/UX standards, styles.
Because usually functionality may open a wide bandwidth for communication and feedback, it makes sense to develop functional UI as a First cut and apply styles and standards later as Cut 2.
5. Main UI functionality – All UI functionality
E.g.: the “advanced” parts would be: “auto-complete”, “Image zoom”, “drag & drop”, “pagination” (instead of longer list) etc.
Story: As a user I can see a list of my monthly credit card transactions.
Cut 1: …in the table.
Cut 2: …in the table with pagination.
6. Fixed view – Adaptable view An ability to provide a user with his specific UI. User-specific UI may appear when we have different classes of users and so all UI or only some of the screens could be:
- Branded for different clients (companies)
- Adjusted to different personas
- Configurable by users themselves
Story: As a user I can make flight and hotel reservations. The tool is used by two personas: end consumer and travel agency. This is reflected in somewhat different behaviors where travel agent may have additional capabilities on the screen to make group reservations. In Cut one we may either:
- Allow both personas use simplest user interface that still covers the needs of both, or
- Build two screens the simplest way possible
And then in Cut 2 we develop the foundation that allows for easy, metadata-based, customization of the screens.
7. Empty inputs – Good defaults
This method assumes not as trivial work in Cut 2 as it seems at a first glance. Example…
Story: As a user I can book flight tickets.
Cut 1: …all controls empty.
Cut 2: …My current location selected as possible place of departure, my most frequent destination – as the one; as I select a departure date the default for return date would be next Saturday after departure.
This example shows that good and useful default values may have non-trivial logic behind it and it may make a lot of sense in separating it out.
8. Single screen – Wizard.
Story: As a user I can enter all necessary information to make my online booking.
In Cut 1 we simply create a single screen with all necessary controls in it. Cut 2 will be a wizard that would collect the data in much more user-friendly manner.
9. Less controls – All controls
Story: As a user I can register in the system.
Cut 1: …providing only basic information.
Cut 2: ...providing richer demographic information.
This can be sometimes extremely useful as simple registration (or other generic function) may enable rest of system functionality work, while next cut will conclude the implementation of more complex registration requirements.
10. Interfacing user – Interfacing other systems.
UI may carry the burden of interfacing other systems, not just the user. Here are few examples:
- Search engine optimization – Web UI should be specially formatted (both visible and invisible parts); content adhering special rules; breadcrumbs navigation etc.
- Access to file system, user directories etc, network locations from the UI.
- Built-in screen printing function
- UI logging and statistics (for further analytical processing)
- Special layout requirements for screens (various reports etc) to be further exported and submitted for automated data indexing
In these cases Cut 1 would be implementing user interface the user and Cut two is extending it to further capabilities of interfacing with the rest of the systems.
11. Main platform – All platforms
Story: As a sales representative I can check product availability in real time.
Cut 1: …with my laptop. Cut 2: …via the interface for mobile devices.
12. Simplest technology – UI framework
Sometimes it can be very beneficial to start really fast development of a, say, classic JSP web page (Cut 1) that implements a story and then only (Cut 2) jump to some advanced UI framework like JSF, Struts or Maverick. This can be done not only in the beginning of the development of a product but also much later on, when UI framework is already in place, but a new piece of important functionality would be much faster to implement using “dirty” simpler methods. Usually these first cuts enable the rest of the backlog to be implemented and then at some point Cut 2 puts the story under the concrete of the framework.