0

i am on the way to learn how to lead a group of developers for projects in RoR using agile methodology. I have found some tools online like VersionOne or PivotalTracker, that can help you create iterations, backlog, stories, etc., so you can divide the work with the front and back-end, and make your developers focus exactly on a specific task.

My question is about the step before you start to use this Agile tools, create stories and iterations, and your developers start to make it grow on each one. My doubts are about the step of Technical, Functional and Non-Functional Software Requirements Specification, so after you have it clear, you can start writting up the stories:

http://en.wikipedia.org/wiki/Non-functional_requirement.

Are there tools that can guide you how to convert the idea of web app (or mobile app) into a list of stories/iterations in a successful way? some kind of visual representation of states, features or functions (and its relationships) where you can specified functional, non-functinal and tecnhical specs, so after that you can create stories?

thank you very much for your time and patient in advance.

Aravind Yarram
  • 78,777
  • 46
  • 231
  • 327
user1106811
  • 297
  • 4
  • 14

1 Answers1

6

You have to change your thought process here.

A user story is one or more sentences in the everyday or business language of the end user that captures what the user wants to achieve. For e.g.

As a front desk representative, I would like to make a room reservation quickly.

As you can see they are

  1. From the user/role (front desk representative) perspective
  2. Goal oriented (make a room reservation quickly)

But they lack details like various flows (payment etc), acceptance criteria, non-functional requirement specific (what does quickly mean in the e.g. story?). You create sub-stories to provide more details.

What makes a good story?

INVEST : Independent, Negotiable, Valuable, Estimatable, Small, Testable

Are there tools that can guide you how to convert the idea of web app (or mobile app) into a list of stories/iterations in a successful way?

Tools like Rally and JIRA allow you to organize stories, sub-stories, sprints/iterations etc.

Some kind of visual representation of states, features or functions (and its relationships) where you can specified functional, non-functinal and technical specs, so after that you can create stories?

These tools provide rich text editors that help us write the stories. Sometimes you have a requirement that doesn't fit as a story

  • A use-case
  • User interface guidelines
  • A list of business rules etc.

Then write something else. Tools like JIRA provide provision for attachments.

so after that you can create stories?

** Stories should be the first activity that should happen. That is the whole point. It is not the after thought. Stories is the way of forcing you to think from a user and goal perspective so you are writing software to meet user goals. **

Stories represent requirements, they do not document them. - Rachel Davies

Agile approach encourages just enough architecture with continuous refactoring.

The sprint delivery team generally includes all the necessary stake holders like business analyst, tester, architect, dba, developers. They collectively are responsible completion of a story/sprint and at the end of the spring, you would have a production ready deployable application. Idea is to incrementally add features.

As you can see from the team composition architect/lead are also involved in each sprint. He, with the help of the team will architect and design just for the stories that are part of the current sprint/iteration (Just enough architecture, Emergent Design). The stories they pick for first sprint are either high risk or architecturally significant ones.

When it comes to design, mostly it is brainstorming and paper or black board based. Idea is to use code as the reference documentation as much as possible and build collective knowledge across the team by pair programming etc etc.

So you wouldn't end up with a poor quality software. You would in fact have the minimum code base that can exercise the stories (you are not accumulating code base for future requirements or nice to have features). Somewhere I read that only 40% of the features built are every used by customers.

Aravind Yarram
  • 78,777
  • 46
  • 231
  • 327
  • thank you very much for your long and rich answer. About stories, obviously it looks like a tool that a non technical person can describe the functionality of the app, but it totally lacks of information related to this functionality, like technical specification.I mean, one thing is writing a user case like "I would like to make a room reservation quickly", but another is all the technical details behind it (data model, front-end, ux-design, non-functional code, etc).So from my point of view, there should be some kind of man in the middle that translates from stories ... – user1106811 Feb 09 '12 at 22:29
  • ... to functional specifications, because if not, you are leaving all the decisions up to the developers, isnt it? i dont see it clear at all. Who is the person that decides for instance the whole data model? agile is about building the data model on demand? Nobody asks from the beggining how is going to be the whole functionality? This approach looks like if you just write user cases / stories, and you dont have technical knowledge,and developers are not committed, you are going to obtain something extremely poor in quality code – user1106811 Feb 09 '12 at 22:34
  • @user1106811 - I've updated the post with clarifications to your questions. See the last sectio. – Aravind Yarram Feb 10 '12 at 00:28
  • ,i have found really good books about designing agile iterations, stories, etc, like "http://www.infoq.com/minibooks/scrum-xp-from-the-trenches", a really good one if you are looking for real user cases, but it lacks of information in terms of functional/non-functional/technical specifications for each story/user case (like all books).I mean, how the project manager would technically specified to developers how to approach each case.Do you advise some book or literature about real scenarios? thank you very much in advance – user1106811 Feb 13 '12 at 09:37
  • 1
    User stories are a good way of capturing business/product requirements. Not sure they are useful in trying to capture traditional functional specification/design type details. The lack of a defined approach for capturing functional specification type detail is one of glaring holes in the Scrum framework IMO and the biggest reason people struggle with it in my experience. – treefiddy Mar 23 '19 at 19:34