This is the second of a four part series on what value a Focus Story brings to agile efforts. In the first installment we looked at how a simple story, "I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth, " can focus an entire nation on a ten-year effort to meet the 'man to the moon' challenge. We saw that while this looks like it has all the attributes of a user atory, a user role "this nation", an action and a goal "of landing a man on the moon", as well as a very well defined definition of DONE – "returning him safely to the earth", It is not. It also contains a time box of "before this decade is out" that started the clock ticking.
What we took from this is a definition of a Focus Story -- a simple, high level statement containing what needs doing, who is involved, and a concrete example to measure getting the job DONE.
This segment will explore how t...
To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
he Focus Story serves to align the product backlog by providing guidelines for common goals and objectives, a tangible statement of DONE, and a timebox within which the story needs to be accomplished.
The Focus Story consolidates the business goals or mission statement of a large effort with the product owner's/ commander's intent, highlighting the most important definition of "done" to a "done by" statement for a given period of time such as a software life cycle phase, release, or even an iteration. If the product owner has developed several 'intentions'; and has organized them into them into a roadmap or a release plan, then all the teams in an enterprise initiative can see the same current picture and share a common view of the future.
From a quality and test perspective, a parallel quality, test roadmap and test strategy is now possible. The Focus Story works as a filter at this level of planning, assisting in the sorting stories by their contribution to what is immediately important from what is strategically important. It adds clarity to what is expected from people adding stories to the backlog. As projects scale, it carries consistency when a second tier of teams appear such as a scrum of scrums or team of teams. Focus Stories also aid in measuring performance as teams can be evaluated by how well they retain self-organization, focus and contribution to group goals. The measurement criteria remains meeting the criteria of "DONE" this offers the highest value for stories spanning the program.
[IMAGE]
Meeting measurement criteria, is particularly important in the case of emergent complex solutions, where the Focus Story becomes better defined as the product owner's intentions evolve. Then the growth of the Agile team structure from small individual teams, to teams of teams, and on to include meta teams all have evolve with the product owner's "commander's intent" to base what is "in or out" and an anchor their collaboration to meet the current expressed intention.
[IMAGE]
Focus Stories and quality assurance and test (QAT)
Since Focus Stories have a clear and definitive "done" statement highlighting the most important goal of the effort, filtering stories based on two criteria such as "return" and "safely" make the Focus Story yet another touchstone for large and growing efforts. The phrase "returning him safely to the earth" exemplifies this. A "done" statement is not just returning to earth but doing so safely. Phrasing like this gives product owners, storywriters and QAT the ability test the acceptability of a user story and filter out stories that do not meet comparable requirements. Concurrently, others on linked projects can apply the same caveats to their day-to-day work without having to constantly apply for and receive confirmation of alignment to mission and intent.
This dual criterion is a crucial step in tracing the value delivered from mission through intent, release, iteration/sprint, and acceptance. Productivity increases as user stories that cannot pass this filter do not start. In well-organized programs with multiple releases, meeting different intents allows more time to develop well-defined stories for future releases. For those stories that do not add measureable value to the intended goal become obvious and should be removed from the Product Backlog, marked "not applicable" and archived, or given an abysmally low priority identifier. In emergent programs, these stories return to their creators for refinement and clarification.
Focus Stories and timeboxes
Focus Stories, by setting a "done by" statement -- make transparent the need to focus on getting the most value short-term, while striving for the optimal value over the long-term. Since the project is on fixed time, it shifts the focus to what is feasible -- that is to say, what can be done in the time allotted --as opposed to what is possible with the right combination of funding, time, talent and luck. "Done by", creates tension in a project. Its benefit to the project, if kept transparent, is to foster collaborative urgency and iterative innovation as opposed to siloed, discrete, incremental improvement.
"Done by" also shifts the role of validation and test. Knowing specifically what a user story has to deliver makes validation and verification the only measurable priority. This creates pushback on conventional development, design and discovery, and shifts their emphasis from elegant solution to measurable result. Encouraging a shift in the team's story selection criteria from technically challenging to technically do-able, asking the question "Is there enough 'meat' in the story, iteration and release to meet the requirements of 'done' that have been set."
The team uses the Focus Story to inspect the individual user story and task to show, in a definitive manner, the Focus Story goal of "done" is being met through the testing of in the user story's definition on "done". Moreover, the story has to show that it can do it within an iteration or sprint.
This chain of traceability ends up delivering a map of the value proposition in the product.
In the third installment of this series, we will discuss how the Focus Story aids in planning and in developing test, development, and release approaches. The final installment will tie all of these together so that a product owner and stakeholder can manage change in direction in a comprehensive manner.
Mike Dwyer is a Principal Agile Coach at BigVisible Solutions. He is a Certified Scrum Trainer and his practice focuses on transforming organization's product lifecycle into hyper-productive Agile teams.
