[University Project]

I want to adopt as many practices from agile project management as I can for a university project. I've decided that the actual development approach will be based upon an FDD (Feature Driven Development) model.

I'd like to tie my features to a user story. When I have my two weekly meetings with a supervisor I can talk about which user stories I plan on integrating on the next iteration, which I've not finished, which need breaking down into smaller tasks etc...

There in lies the problem, I don't have a user. I could "be the user" but I think there would be a conflict of interest seeing as I'm managing and developing the product.

Any suggestions on how to cope with a situation where a particular user hasn't been identified?

For reference, project notes are available at imat3451.blogspot.com

4 Answers 4


Just because "user story" is titled as such, doesn't mean that user's write them. Rather user stories are captured / written to capture user behavior or "the story" of what the user wants to achieve.

You have 3 hats on this project. The role of the PM, the role of the developer and the role of the user:

  • Put your user hat on and think about what the problem is, that you want a solution for.
  • Put your PM hat on. Start at the "epic" level and think about the larger blocks that will make up your project and provide a solution to the problem you as a user have. Break out these larger pieces into "user stories".
  • Keep you PM hat on and plan your first iteration.
  • Put your development hat on and double check / accept the work you have in your iteration.

If your new to the "agile" scene I would highly recommend INVESTing some time upfront in what it takes to write a good story. The invest mnemonic is in my opinion one of the most fundamental aspects of writing good stories that often gets overlooked.







  • thanks, its the first time I've come across that accronym (more use to TLA's)
    – Luke
    Oct 28, 2011 at 0:05

One option you may want to consider is this. For each feature write the stories that you think make sense. Once you are finished, e.g. all stories for one feature, then try to collaborate with a different student who has to run a project themselves. They can review your stories and you can review their stories. Both of you will learn.

Alternatively you could ask a person who you trust and who has experience to review your stories. Maybe you have a friend, an acquaintance or maybe a mentor who can help out.

Software engineering is very much about communication in my experience so all of the above will help you beyond the project at hand. Good luck!

  • Unfortunately / Fortunately I'm the only student doing this, the module basically consists of 300 hours self directed study the deliverable for which is a software product. Theres not even someone else making a similar application in a different language.
    – Luke
    Oct 27, 2011 at 0:55
  • 1
    In that case maybe you could go for the option mentioned in the second paragraph in the answer. Without any feedback at all, how would you ever know whether your stories are good? However, with a lot of discipline and self-observation you may be able to achieve something, too. For example as you work through the stories mark the ones that were easy to understand and implement. Write more of those or revisit others to improve them based on what your observation is or what you learnt. Go from there.
    – Manfred
    Oct 27, 2011 at 5:19

If you don't have users you can talk to, identify types of users you can target stories at. For instance, if you were making a website where people could post reviews of products, you might have users like:

  • Reviewer (someone who posts new reviews of products)
  • Consumer (someone who reads reviews and posts comments)
  • Moderator (someone who can edit or remove inappropriate reviews or comments)

Thinking about a feature from the point of view of of these users can help you focus on what is important to that type of user.

You can even use your user roles to prioritise what order to do your features in - perhaps as a fledgling review site, I'm most interested in attracting reviewer type people to build up my content so I'll prioritise those features that are geared towards those users.

  • Cheers, I'll take that on board, my main concern was that as a developer the use cases I'd identitfy would seem too "rehearsed" and I'd rather deal with a genuine user issue early on than blind-side myself to potential use cases on account of knowing what the software is designed to do.
    – Luke
    Oct 28, 2011 at 0:09

Well in our case we had a user, however our approach has been for team to do, say 2 days of research on the features w.r.t trends, competition, how is it implemented generally, best practices and what we as a team think, has to be minimum stories.

Planning session, a lead provides context with benefit of doing such a feature. Team will write their views on what stories should be done to achieve that benefit on post its. Lead categorizes the stories (post its) on a wall into high level categories and removes all duplicates.

We prioritize the remaining stories in each category and schedule them in sprints. Effectively who ever has come up with the idea or have view into vision/goals can become the user and drive it.

You did talk about a developer may struggle to fill in user role, however with a combination of whole team sitting in planning will neutralize this with majority voted stories taking the top seat. Needless to say however you do and what ever you define as story should clearly provide you with value.

  • Thank you. I've written them myself and have some "must-haves" some "could-haves"
    – Luke
    Oct 28, 2011 at 18:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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