Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

In an Agile development process usually the main focus is on User stories, but sometimes a single requirement may span several user stories.

For example, the client may request a search page for all users in a forum, and there are several actions that can occur on each user such as ban user, delete user, reset Password, etc.

We may divide this feature into at least 4 user stories:

  1. Search for users
  2. Ban user
  3. Delete user
  4. Reset password

How would the user interface designer implement such a user interface? Should he/she work on the first user story and then start incrementing more features to the UI? However, I think the final UI will be messed up!

If he decides to work on the whole feature (search + actions), what if the actions where of low priority and would be implemented several iterations after the search functionality was done?

share|improve this question
6  
This highlights the mistaken idea harbored by some people that agile, however you define it, is something other than a project management tool. You still need someone to look at the entire product from an architectural standpoint and make sure all of your stories add up to something coherent. –  Blrfl Apr 2 '13 at 11:45
    
would the down-voters plz explain why?!! –  Songo Apr 2 '13 at 14:25
    
@Songo: No, down-voters normally do not explain, it is too much effort. :-( –  Giorgio Apr 2 '13 at 14:59
add comment

4 Answers

up vote 12 down vote accepted

Take it iteratively. You're working directly with the users, right? So it should never really be a mess.

First do the search page. You and the users should keep in mind that they'll want to be able to do actions on the results. Do the users like it? OK, you've got your search.

Now add the "Change Password" (or whatever is next in priority). Oops, we need to change the search page a little--well, change is often part of the game. Do the users like it like the results? Good.

Now add the next item, and the next...

The agile approach says you always have feedback right away, so you should be good.

That said, there's no real reason why you might not be able to attack 2 of these stories in the same iteration (adding delete user AND ban user). The key is to always be working with the customer to make sure it's right.

You're often (always?) going to end up with users thinking of something else they want to do from that search screen after your original "design" is done and implemented. So, you'll end up modifying it at some point anyway. Just approach the whole thing with that expectation and you should be good.

share|improve this answer
add comment

I feel like I say this a lot. Agile does not mean you need to put blinders on to ignore the future and design yourselves into a corner. Agile is about how you deliver functionality, and has very little to do with how you design functionality.

In other words, it's okay to look as far into the future as you want when creating your design, as long as it doesn't postpone the delivery of functionality in the short term.

What that means in your specific example is that you go ahead and design the user interface such that it will be easy to add actions later. However, if working on getting the actions design right would delay delivery of basic user search by an iteration, it's better to do a design without actions first, assuming a search without any actions has value to the customer.

The question to ask yourself is, "Is this design work delaying my first delivery?" Most of the time, the answer will be no. You have to do a design anyway, all you're changing is some design criteria.

share|improve this answer
    
+1: Very good answer: "Agile is about how you deliver functionality, and has very little to do with how you design functionality." I think too often agile is used as an excuse to justify the absence of upfront design (e.g. if a developer is not willing or not able to do it.). Instead, one should schedule activities (user stories and sprints) after the overall plan and architecture has been prepared (of course you might need to adjust the architecture as you proceed with the project). –  Giorgio Apr 2 '13 at 14:57
add comment

The first user story can be the design of the whole interface -- they don't have to design just one piece of it. It is the design as a whole that adds business value.

That being said, I see at least two distinct features here: the ability to search for users, and the ability to perform a function on one or more users. The designer could tackle each of those searately if that makes more sense.

Remember: the goal is to deliver quality software, it's not to blindly follow some methodology. Ask yourself whether breaking the design up into pieces helps or hinders that goal. There are no scrum police, only happy or dissatisfied customers.

share|improve this answer
add comment

I had an opportunity to intern at an Agile/Extreme programming factory. They were using story-cards to drive the iterative development process. Each story-card drove an implementation or change. The key was user interaction. How can one successfully design an interface meant for a user without interacting with a user of the software?

A possible scenario is to begin with user interaction to decide what the user wants first. Then, iteratively, design the UI based upon increasing feedback, user priority, and what the user must have.

The user stories are there to drive how the user would interact, at what level, and in what manner. But they are only approximations until interacting with the user. If there are a multitude of users that would all desire something specific, then a small survey of people may be in order to define some baseline for the UI.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.