I was going nuts about BDD recently. One of the most exciting things about it was the idea of doing all of the UI first. The idea is to deliver something to the client before too much of the back end is developed, so they can say if you’re on the right track — apparently this is a major agile tenet.
I’ve thought this way for a long time. For my current job’s interview, when asked how to start a project I replied to do all the UI first. I don’t think that’s what any job actually wanted to hear, I know I’d given that answer 100 times before, and I know no one ever liked it. I got lucky that the group I interviewed with was in such disarray they didn’t realize it probably wasn’t the answer they were supposed to be looking for. But that was years ago, so maybe that answer makes more sense in these agile driven days.
Oddly, this wasn’t covered in the 3 day agile training I recently finished. Maybe it’s covered in the recommended 5 day version.
My issue has been trying to write user stories that only cover the UI without basically duplicating all user stories and adding “UI” to them. I originally went with one user story that just had (basically) “do all UI”. Artie rightly pointed out that is an epic, and needs to be broken down for user stories.
The best I got was to break it down by themes. Take Quizmo as a simple example.
- All Quiz Management UI
- All Question Management UI
- All Quiz Taking UI
- All User Management UI
- All Student Viewable Reporting
- All Admin viewable Reporting
I don’t actually think this is right, because this relies on implicitly knowing all user stories from the get-go. Perhaps the right way would be to have 2 sets of story points for each story, one for the UI and one for the complete execution. This would mean running the same story card twice.
I’m sticking with the “UI by theme” approach for now.
Do you think there is a way to express those tasks in story form in order to better break them down? Perhaps more descriptive of UI, such as “as a quiz administrator I would like to view a list of all respondents and their scores.”. Obviously that incorporates both UI and functionality, but then attached could be a mockup of the page — story boarding your UI first then building it along with functionality during the sprint.
Not exactly what you are going for, I know, but I thought one of the tenants of agile was delivering *working* functionality, whereas it sounds like you want to use a sprint to deliver a mom-functional prototype, which might be better accomplished through mockups or wireframes, created in the planning process rather than in the sprint.
I don’t like the process or wireframing I’ve been privy to. Usually it’s just mockups made with Photoshop which is not altogether helpful. I want the HTML/CSS/some of the js done so the client can get a feel for the project as opposed to a cursory glance. A sortof example of what I’m talking about was discussed in my training session. After the first sprint the client can see the login screen but it doesn’t log in to anything yet. At the end of the second sprint they can log in and see a second screen that doesn’t yet do anything.
So I disagree that them seeing the views without them functioning is not delivering functional software. Just incomplete. My point is to allow them to make changes before things are too far along.