One of the things that I love is mentoring and coaching some of my past students as part of a life-time commitment to grow people and grow myself. I engaged with a group of such students from my training batches who were talking about iteration planning. As part of the conversations, I felt that the primary reason for doing iteration planning in two parts was becoming more of a transactional "this is how we do it here" mindset rather than practicing the transformational "let us rethink why we do what we do and how to sow the seeds of success" mindset.
In Agile framework, we promote the approach of INVEST property for a user story. It stands for independent, negotiable, valuable, estimable, small and testable. Now, is there any connection of this approach to the 2-part iteration planning! In the first part, the expectation is that the product owner identifies the prioritized stories based on the iteration goals and objective (which should be aligned to the product strategy and organizational strategy). This first part ends when team members have agreed to work on a story. In the second part, the team members estimates the work required, divvy up the story into its constituent tasks and agree on the criteria used to validate the completion of work. The second part ends when the entire team has committed the specific stories for the iteration starting the sprint!
So, how does INVEST apply to these two parts? I suggest we break up the INVEST itself into two parts. Every component of INVEST drives the concept of risk in development so that the team makes the logical decision during iteration planning and yet take calculated risks for experimentation. To me, this approach extends what I call risk driven development (RDD).
- The first part INV is associated with part 1 of the iteration planning. The focus of this part is answering the question, "Does the selected stories add value to the user, customer, stakeholder?"
- While the product owner is accountable for the stories to be selected, the team is equally responsible to consult with the entire team and inform how stories may have to be split to avoid dependency (one user story waiting for another user story to be complete), which is against the lean principle of flow. When this is done, the stories agreed or independent!
- The product owner may only look at commercial or user perspective. It is the team's responsibility to negotiate with the product owner on how some other priority order of user stories may have to be done to set the architecture for features coming up in the future? Furthermore, the team is also given the space to experiment with some "should" or "could" type of stories rather than commit to all the "must" stories with no opportunities to fail forward! (Rajagopalan, 2018)
- As part of these negotiations, the entire team is focusing not only customer and business value but also on the technical and process value (Rajagopalan, 2019). That means the combination of stories are valuable.
- The second part EST is associated with the part 2 of the iteration planning. The focus of this part is answering the question, "Does the selected stories fit into the iteration?"
- The focus of timeboxing is to facilitate sustainable pace (which is one of the 12 agile principles). So, the team pointing exercise is for the team to collectively estimate the individual stories and evaluate if the set of stories can be done (Rajagopalan, 2016).
- While each team member can contribute to the collective story estimation (e.g.: Planning Poker), the stories should be small enough for the team decompose the stories into the tasks (for completion). The team should not commit to five 13-point stories as the risk to delivering them may be higher. The more they fail on finishing the story in the iteration, the more they will be demotivated seeing the charts on planned versus actual velocity! There is a reason why we use a geometric sequence for points to facilitate this complexity in stories.
- Finally, stories should be with the intent that once it is approved, it can be deployed! Granted there are other considerations like single cadence, multiple cadence, and release on demand for ensuring value delivery. Nevertheless, what are the things to validate as part of the verification and validation? That is part of the acceptance criteria (called confirmation as part of the 3C's of a user story). So, in addition to tasks for completion, testability of the user stories should be factored with multiple test cases (involving a combination of manual, automated, scripted, exploratory) for every user story aligned with the product owner acceptance criteria. Such a notion is a prerequisite to test driven development (TDD), behavior driven development (BDD), acceptance test driven development (ATDD) and hypothesis driven development (HDD).
