4

Do we still create/maintain a copy of a product specifications when subscribed to the Agile/Scrum framework?

I have been tasked to provide a product specification as team members would like to always have an 'overview' of the functionalities/features of the product we are developing.

Does this make sense or do we stick to the product backlog only?

  • 1
    What aspects of a "product specification" isn't covered by your product backlog? – David Arno Jan 5 '15 at 13:51
  • There's nothing wrong with an overview, but engineering for features that may never make it into a Sprint violates the YAGNI principle. – Todd A. Jacobs Jan 5 '15 at 23:43
7

Product Owner is required to develop a release roadmap

Contrary to popular belief Scrum does not mean seat-of-the-pants management with no advance planning. The Product Owner is required to develop a release roadmap. However, there are two key requirements for a release roadmap in Scrum:

  1. The timeline in the release roadmap should be based on actual velocity of the team.
  2. It should be made clear that the next release is nailed down but further out is a forecast that will change based on market conditions and customers contract signings.

If you need help with the process of developing such a release roadmap and the format for presenting it, I can recommend the Goal Oriented (GO) Product Roadmap by Roman Pichler.

0

To me, the concerning word here is "specification". I don't know what it means in your organization, but I'm used to it meaning a comprehensive description of the scope of the product. The development team should be trying to solve your user's needs, not fulfill a list of requirements in a spec document.Again, I don't know what a product specification is in your organization, but the concern would be that you're working with a fixed-scope project where the developers are rewarded for completing tasks to a spec, not creating valuable software.

Like Ashok mentioned, a roadmap can be very helpful. However, remember that in agile we value responding to change over following a plan. Every step of the project is an opportunity to learn more about your customer's needs. As such, most projects find that their roadmap is wrong at some point through the project. It is important that you can change the roadmap as needed without unreasonable amounts of effort and without creating problems for yourself in your organization.

0

The answer here is unfortunately...maybe.

It depends upon your organisation and the kind of development you are working in.

In our department we have Business Requirement Specifications in addition to the Product Backlog.

The reason for this is two-fold

  • We have multiple projects coming into the same Scrum Team
  • We have large scale dependencies that we require to be completed by other departments prior to the Scrum Team beginning their work. Since they require a BRS and we input into it it makes sense for us to help write the BRS and make sure our Backlog is reflective.

For instance, our department handle Front End Business Warehouse and Business Objects Development and the Product Owner can speak on behalf of the Business.

However the SAP R/3 architects (separate) require detailed specifications regarding the Business Warehouse back end preparatory work. Therefore the Business Requirements Specification are produced although we have a more complex Product Backlog which we can draw upon for Task-Level Sprint Planning.

I would argue that you absolutely should have a detailed requirements document if any of the following are true

  • The Scrum Team are upstream or downstream of another non-Agile team producing the same product or a derivative of that product
  • The Scrum Team / PO must anticipate the business needs of multiple projects, work streams or backlogs
  • Non-Traditional Scrum processes are diluting the Scrum Framework due to business constraints
  • The Product Backlog is highly technical or a complex project and resistant to User Story Breakdown EG SAP Master Data with 1000+ stakeholders across global landscape. There is very few ways of getting around the need for a large document detailing the exact scope, out of scope and risk management of this piece of work.

The truth is most Scrum examples always use the simplest possible explanation without considering the tailored work environment.

Not every Backlog can be

As a Customer of Amazon I want to be able to put items in a basket for future checkout.

The Benefits of Scrum for our team are that we can respond exceptionally quickly to project changes, we can filter and work on multiple projects at once as a merged backlog, our capacity planning and sprint cycle provide more realistic planning timelines (they get an iteration time box and they can get some work done in that box, if the work exceeds the box, ask for another box) and most importantly we can foster innovation and cross-functional development.

0

surely the Product specification should be the features and themes as defined and agreed with the Product Owner as part of the Product Vision (or whatever name you wish to give it)?

I prefer not to use 'roadmap' for this as roadmap to me conveys the notion of how you're going to get there, e.g. release plan.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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