Mauricio Zamora, my collaborator on a number of other projects, recently took the time to do a thorough review and critique of the new whitepaper A Lean and Scalable Requirements Information Model for the Agile Enterprise (available on the resource page). He raised a number of supportive, as well as differing points of view. I thought I would call them out here for any that care about this particular approach to implementing enterprise agility. Note – all the words below are Mo’s, not mine.
“On The Big Picture – Very helpful to the understanding of the enterprise model.
Stories – the two most important things I always stress with stories are
- Must fit in one and only one iteration
- Must have well defined acceptance criteria Stories
The “Other Work Items” call out is confusing to me. For me, it’s just another “story” (perhaps a type of story). Minor but to me any kind of work – regardless of “type” is a user story. Stated differently, I look at things like: • Top Node = You call Story, I call “User Story” • Bottom Node 1 = User Story vs. Functional User Story • Bottom Node 2 = Other Work Item vs. Technical User Story
User Stories & Tasks – I have found that the need for “tasks” ultimately disappears as a team matures. As a result, creating tasks ends up being just administrative and duplicate work. This happens for three reasons: Stories start to become more granular • The Acceptance Criteria becomes more clearly and as a result serves as the “task list” itself • In some cases, teams shift from “assigning” work upfront to a “queue” concept – the entire team owns each story and once one story is done, members of the team grab the next story in the queue. Task management helps though initially when people are still struggling with how to break work down
Features – only thing you may want to highlight is that features serve as the foundation for creating cross team coordination. Stories are targeted at one team
Feature Testing – this is a very difficult problem. We have struggled with this one tremendously. We are getting better and recently, we finally were able to establish a truly dedicated “integration team”. They run as an iteration team within the same cadence. They are usually an iteration or two behind the rest of the crew but their job is to automate tests across components. By the end of the release, we have team driven automation (driven from stories within a team) and cross team driven automation (driven from features across teams). • This is a major struggle for everyone I talk to – would be a good focus at some point for your blog, future books, etc.
System Qualities & Non Functional Requirements This would be a great topic to expand upon in a series. You could describe how to establish a team at this level, how things are vetted and added to the backlog, etc. In addition, the topic could be a bit broader – for your specific requirements work, you could cover all the vision & roadmap creation and release planning activities – including ownership, techniques, pitfalls, etc. It is a complex topic because it tests a lot of the agile constructs – you can’t always involve the entire team, etc.
Portfolio Level – I am not sure the Portfolio constructs only apply for large scale enterprises. There is one fundamental challenge that anyone will face and it has to do with the understanding of when an initiative (collection of features) is considered “done”. Take for example a company that is in the process of closing a deal – to close the deal, the company knows they need to tackle 10 features. However, those 10 features are only a subset of a larger feature backlog. Another deal in pending may require 10 features as well – some overlap, some are different. Without the concept of an initiative or “epic”, you lose sight of when that particular initiative will be done. This applies to even small teams. What you are looking for is a measure of functional completeness that goes beyond “scope” or release boundari
Here is an example:
- • § Land Google Deal (Your epic / initiative) ·
- Features 1-10 required • § Land Yahoo Deal (Your second epic / initiative) ·
- Features 1-8 required · Features 11, 12 & 13 required
Strategic Investment Themes -The comment about % investment is dead on. It is so easy to not be making the investments that are determined by strategy – due to firefighting, misalignment amongst teams. Making sure you are actually doing what you decided to do at release planning time is a critical factor in ultimate business success.
– end of Maurico’s Comments