... you will never turn back
(Berlin, Germany) Sometimes the most obvious Agile concepts are not so easy to be applied when we need to make a practical usage of them. Specially if we need to bring into a consistent and common understanding a product or portfolio vision for later implementation. My goal with this post is to share a very personal opinion about how and whom should fulfill those Agile requirements levels.
Requirements engineering are layered with increased levels of detail, from strategy with higher level descriptions of the portfolio or product vision, into expert levels of requirements to implement properly the product, feature and story.
We learn with Agile and Design Thinking that short and small goals are incrementally shaping the strategy into real products. (Revisit the post: How Design Thinking can be extremely useful to support digitization in traditional industries ). We saw it how important is to test the concept in small proof of concepts, once we arrive into product and feature levels. But, in Agile, strategic levels in the hierarchy also have a role to play supporting requirements!
Through Sagas our managers should communicate not only the portfolio vision but also:
- The desired differentiation compared with competitors;
- The incremental performance;
- The incremental functionalities;
- The innovation ambition;
- The cost reductions;
- The budget distribution criteria;
- The shared goals between products: quality, cost reductions, architectural optimization or shared components, contract negotiation with common suppliers, etc
Summarizing, saga is the level of requirements used to express Portfolio requirements and desirable optimizations and synergies between owned products.
Who should write Sagas?
In my personal point of view, Sagas must be written in the Top strategic level of the organization until the Product Portfolio management level.
What should we write in the Epic level of requirements?
Epics are, in my view the requirements level for products. Should be written, as much as possible, respecting the same story structure: Who? What? Why? How?
Typical content for an Epic:
- Here is where the Product Owner should express his ambition for the Product.
- In my view the Epic level of requirements is the most suitable level to explain to the team the business context to require the set of features or requirements grouped at this level.
- Some features are so complex that they represent by their amount of stories or complexity one single Epic.
- An Epic should also reflect the requirements coming from the level above, from the Portfolio level, expressed by Sagas. Specially for shared requirements across products in the same portfolio.
- We also should include particular non-functional requirements who will be applied directly for the described feature or set of features: Quality Assurance, Security, Legal requirements, etc.
Who should write Epics?
In my personal point of view, Epics should be written in the Product level. And by whom it depends of the industry and how is structured the organization. If we are in Software or Digital industries normally the Product Owner is who knows the Product and knows processes, market and how the business must be driven. If we are in more traditional industries, where the core business is not software but is supported by software, we can find often a product owner representing the Business and a product owner from the IT department shaping the specific technical requirements. This role of IT Product Owner can be performed by an IT product owner himself, by a Scrum Master or by a senior Architect. Normally this is a role for the most senior resource able to structure the requirements to be “consumed”/ understand by the Dev Team.
I must say that write requirements is probably one of the most important roles in the organization and should be performed by who owns the knowledge and not the highest grade in the hierarchy. But the big thing with Agile Transformation is this: since strategic levels, requirements must guide implementation.
Stories, Tasks and Sub tasks
What should we write in the Story level of requirements?
Personally I would say, a story is the lowest level of detailed requirements. The nature of the requirement, as in the levels above can vary: technical story/ non-functional or functional and with direct impact for the user, for the product, for the feature. Often, due to some features complexity, they can be breakdown in different stories. And than, linked, grouped, related.
Agile doesn’t survive without Quality and Testing, and defects or bugs also must be written, properly describe to be replicated. The responsibility to report bugs and defects are not only restricted to test engineers. This is an overall responsibility and all should write them.
Regarding tasks and sub tasks, I would say they are not part of requirements, but simple steps to support the implementation.
Who shall write them?
In my point of view all team should write stories, of course take them or not is a Product Owner decision, and their prioritization is also his responsibility.
Freedom to customize issue types per team or organization
I must say that the customization of the issues naming and meaning, varies a lot from one organization to another. But the important part here is all group engaged around a backlog must share the same meanings.