How do I split these 40 stories?

A student from last week’s Agile Bootcamp Class taught at Harvard University (yes, that Harvard) asks,


Question: I have a project that involves 3 different users who want approximately 25 new fields on an application. Most of these fields are view only with the exception of 4-5 fields which allows input changes. However, user #1 wants to see all 25 fields, user #2 wants to see only 10 of the same fields, and user #3 wants to see 5 of the same fields. How should I approach writing these stories? Would I write a story for each user and each field – which could potentially be 40 stories? Or should I just combine the fields that all 3 users would want to view? For example, one field might be “name”. My user story might say“As a user #1, user #2, user #3, I want to see all names of employees eligible for an annual salary increase so that I can view all eligible employees.”


Answer: This sounds like an interesting set-up. My answers, of course, will be a bit general because I don’t know all the specifics. Also, I will make more stories if the developers are unfamiliar with the systems / tables / data, and probably fewer stories if the team knows quite a bit about the different systems. With caveats out of the way, let’s dig in! First, 40 stories? Yuck. Too many. Second, because you have 3 different users, I would start with stories for satisfying all of them (unless there is a reason to focus on just one). My presumption is doing this adds value the quickest, which is my guiding answer for how to break up stories.

  1. As user #3, I want to view < information from 1 field> so I can do my job.
  2. As user #3, I want to see < more information > so I can . . . .
  3. As user #2, I want to view < even more information > so I can . . . .
  4. As user #1, I want to see < all the information > so I can . . . .

The point of #1 is to prove we can display information, while the other stories add more details for the same and additional users. None of these is about editing the data. Depending on what keeps the users and developers happiest, there are a couple of options. I can insert story 1A; Edit the first field. After this I would insert more edit stories, probably grouped like the last 3 stories above, as appropriate. A different approach might be to insert the edit stories after the last story. Again, where is the value?

A couple side notes:

  • It doesn’t make much difference if you use “see” or “view,” the goal is understanding, not the worlds best grammar.
  • I would be remiss if I didn’t mention the value statement in your user story is a bit weak. What is the specific reason to view eligible employees; the actual awarding of salary increases, a validation check, a fascination with other people’s salary, something else entirely?


  1. Johna521   •  

    Very energetic blog, I enjoyed that a lot. Perhaps there is a part 2?

  2. Mike DeCleene   •  

    (Sorry for the late comment – last weeks were crazy).

    I think your advice given the setup is pretty much right on. However, stepping back, I think the bigger picture is the way the question was presented reflects a lack of understanding about user stories, and you might want to think about addressing that.

    User stories aren’t (primarily) a way of “breaking down” a given known and precise scope that we’ve already decided on into bite-sized development chunks. They’re a way of organizing our thoughts on how to approach a business problem.

    In the setup, it’s already been decided a.) there are three primary users, b.) there are 25 data fields, and c.) which fields each person needs. The only task is getting those database fields to a screen somewhere.

    How did we get to those conclusions? A user story approach would be to start by thinking about users and needs, not database fields. We might find we don’t need all the fields, or we need more fields than we have.

    Walking through a hypothetical – let’s say the database in question is personnel data, and we’ve identified three primary usage scenarios – an employee seeing information about themself, an employee seeing information about someone else, and an HR person seeing employee details.

    If I were going to generate stories, I wouldn’t think about fields – I’d think about needs. So, the simplest thing I might try is “An an employee, I want to see basic contact details for a known employee in the system, so that I can get in touch with someone I need to work with.” No “is this me?” check, no search, just type in a specific name, and go. We can decide as part of the story what “basic contact details” means – name? e-mail? cell phone? It also suggests some things will likely be out – payroll information, salary, disciplinary actions. It will likely suggest a UI of some sort (possibly simple).

    It also asks questions that are potentially more interesting than just “which fields are next?” The obvious one to me is “search” – do we need a story for that? If so, do we have simple and advanced? It also suggests some directions we can take this. Is there a way for me to choose which details I want to share publicly (e.g. my personal cell phone number)? If I’m looking at my OWN record, what should be different? What other classes of information do we have out there (“basic contact info,” “social media contact info,” “payroll information,” etc.)? Do we use this system just as a display, or to maintain the data in the system (e.g. can I “manage” my list of direct reports)? Can we delegate certain responsibilities?

    Thinking about functionality allows us to make decisions based on USAGE – what do we want to enable? What’s important? We want to focus on who and why, not what.

    If the questioner is just using stories to “package up” a set of database fields for delivery, they’re sort of missing the point of using stories in the first place.

Comments are closed.