4

I know there is a distinct difference between a requirement specification and a user story. However in our company, many of the requirements can actually be defined in a standard template. This goes for small and medium sized business applications based on a single SharePoint site. I have found that it is much easier to use a standard Excel document with sheets for:

  • Permission groups
  • Access management
  • Lists + plus definition (Columns, settings, etc)
  • Libraries(Columns, settings, permissions, etc.)
  • Workflows.

So basically in one standard Excel document, I can describe all the requirements for a given solution.

  • It's easier to define, and get user acceptance.
  • It's easier to develop
  • It's easier to test

The question is how this would transfer into User stories? I think it is too big to keep in one user story, but on the other side, I do not want to break the Excel sheet into multiple sections. So how would one work with standard requirement templates, while sticking to the Agile Manifest?

mcottle
  • 6,152
  • 2
  • 26
  • 27
CADmageren
  • 43

2 Answers2

5

The Manifesto for Agile Software Development doesn't say anything about methods. It, along with the principles behind it, talk about things like people and interactions being favored over processes and tools, collaboration over contract negotiation, responding to change over following a plan.

It's totally fine to follow an agile development model and use your current tools and formats for capturing requirements. However, look at how well you adapt to instances when those requirements change and how you convey information among the members of the team or between the team and other stakeholders.

Thomas Owens
  • 85,641
  • 18
  • 207
  • 307
4

Work with the developers

The best solution here is to have a conversation with your developers. Find out the reasons they want stories, and share with them the reasons you don't want to give it to them. Be prepared to compromise, and be aware that as part of an agile team you have but a single vote.

I think your goal -- especially because you seem to just now be learning about agile development -- is to optimize for the team and not just for yourself. It sucks that it might mean more work for you, but the team exists to build products, and if the most efficient way to do that is with stories then you should give them stories.

Stories are a very effective way to describe small units of work. As a product owner, you can certainly use a spreadsheet to manage your own work, but the work that the development team does ought to be based on stories if you're doing agile development1

I think you need to continue to create story cards for the team, but perhaps you can add to the story card the spreadsheet rows that the card represents, so that you can help keep track of which stories are for which requirements.

Stories are greater than the sum of their parts

Story cards are much more than just some busy work required by a methodology. They provide real value to the team by forcing the team to define or acknowledge who a feature is for, and what the business value is. Even if that data is repeated on 20 cards, it helps to reinforce why the story is important. It helps keep the customer ever present in the minds of the developers.

Beyond that, story cards are an excellent focal point for the daily stand-ups. Instead of everybody looking at a row in a spreadsheet, you can have a real, tangible object to hold and look at and interact with. Believe it or not, there is a real psychological boost from being able to physically move a story card into a "done" column -- something you simply don't get by typing a string into a column on a spreadsheet.

1Ok, if you're really agile, the team can do whatever works best for them. In such a case, this is a team decision not a product owner decision, nor a people-on-the-internet decision. Let the team tell you what works best for them, then give that to them and stay out of their way :-)

Bryan Oakley
  • 25,479