You are viewing a read-only archive of the Blogs.Harvard network. Learn more.

Agile: doing UI first

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.

2 Comments