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,122
  • 2
  • 25
  • 27
CADmageren
  • 43
  • 2

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
  • 79,623
  • 18
  • 192
  • 283
  • Thanks, perhaps I need to take this with the dev team once again. They are so insisting on following the procedures and tools (Jira). But how would you span a standard requirement spec over multiple stories? – CADmageren Jun 14 '17 at 19:45
  • 2
    @CADmageren A requirements spec is just a collection of requirements. Usually, each individual requirement (in my experience) is presented as a "shall statement". A user story is a statement of need and a collection of acceptance criteria to determine when the need is met. If you're using a requirements spec, I wouldn't be using stories. I'd just treat the spec as a living document that is worked from and there are no user stories at all. If you wanted to put work in JIRA, put in tasks or something that ties to things in the spec. – Thomas Owens Jun 14 '17 at 20:08
  • +100 Do what works for your team. – RubberDuck Jun 14 '17 at 22:40
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,192
  • 5
  • 64
  • 89
  • 1
    You almost got a downvote, then I saw the footnote. – RubberDuck Jun 14 '17 at 22:40
  • I know this is a classic discussion, but if "The developers need stories", this adds additional work on me. And this is really my problem here. If I have collected the requirements in a structured and standardarized way, why should I change focus and describe the same thing from a user story perspective? For a SharePoint site, lets say, 80% can be described in a standard format. But the developer team insists I split this into User stories, because this is the "agile way". – CADmageren Jun 15 '17 at 09:02
  • 2
    @CADmageren: no offense, but I think it's irrelevant if it adds more work on you. The role of the product owner is to serve the development team. The goal is for the _team_ to work as efficiently as possible, not to make any one team member as efficient as possible. If the agile team wants stories, that's what you should give them. Ask yourself what your goal is: for the team to be as efficient as possible, or for you to have less work. In this situation, it looks like you can't have both. – Bryan Oakley Jun 15 '17 at 11:44
  • It is also my goal to have the team work more effective. I am not complaining about my team, but trying to understand agile development... see the light. – CADmageren Jun 15 '17 at 20:42
  • @CADmageren: since you appear to be new to agile, I recommend sticking to the best practices, which includes creating story cards. Story cards aren't just busy work, they provide a lot of value. I've elaborated on that point in my answer. – Bryan Oakley Jun 15 '17 at 20:53
  • 2
    To answer your question about "why should I do this", turn it around. The developers want to know *why* they are building what they're building. If we don't know *why* we're building a thing, it's possible (nay, ***common***) to build software to spec, but not realize the value it's meant to bring. Also, it would be best if you just asked the team why they want user stories. "Individuals and Actions over Processes and Tools". Be personal and direct with them @CADmageren. http://agilemanifesto.org/ – RubberDuck Jun 15 '17 at 23:53
  • 1
    I don't agree with the attitude of "give the developers what they want" and I don't agree with the comments that the PO should take on more work because the developers want things in a different format. It needs to be a conversation. Why does the development team want user stories? If the answer is "because it's agile", that's bogus - being agile doesn't mean using user stories. But they may also have good reasons. "Individuals and interactions over processes and tools" means having open and frank conversations and adjusting the process rather than having rigid processes and using poor tools. – Thomas Owens Jun 16 '17 at 00:45
  • @ThomasOwens: I agree it needs to be a conversation. I'll see if I can make that more clear in my answer. – Bryan Oakley Jun 16 '17 at 00:51
  • Thanks. I'll check it on it later (please do ping me, but I'll revisit sometime tomorrow). Note that I don't think that this answer is *wrong*, so I don't plan on downvoting it. – Thomas Owens Jun 16 '17 at 00:53