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