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?
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:
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.
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.
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
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 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.
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.
