SPACE Framework

SPACE framework defines key components (stages, tools, practices, roles) of the product management practice and is covered by several interrelated domain models that deal with different aspects of agile product management:

  • GALAXY fundamental beliefs model
  • GEO product management model
  • SUN product definition model
  • JUPITER requirements capture model
  • VENUS backlog building model
  • MARS sprint management model

GALAXY fundamental beliefs model 

GALAXY (Global Agile Leadership AXiology) is a fundamental beliefs model that assists Product team in recognizing key principles and values that govern all of its activities. This model does not provide for specific practices to be performed, tools to be used, and roles to adhere to. However, it helps a lot in setting the stage for Product team’s focus and performance.

Key principles

SPACE is based on several key principles some of which are shared with common agile and lean frameworks:

  • Value creation
  • Customer satisfaction
  • Economic view
  • Systems thinking
  • Simplicity of management and technical protocols and practices
  • Changing requirements expectation
  • Iterative workflow
  • Built-in quality means and technical excellence
  • Fast incremental delivery
  • Radical transparency
  • Team engagement and empowerment
  • Continuous protocols and practices improvements

and others provide for its own target application circumstances:

  • Consideration of clients’ process cadence / rhythm – sprint length is established according to natural rhythm of the client so to synchronize client’s and product cluster / portfolio teams timeframes;
  • Consideration of client’s time constrains for delivery – product backlog items are prioritized and batched into the sprint backlog taking into account clients priorities that must be met by a certain deadline;
  • Consideration of whole product’s lifecycle / evolution path – team is responsible for the product in its entirety, its whole and ultimate lifecycle / evolution path, therefore, product roadmaps and various backlogs (product, sprint, daily) include items related not only to development and release phases of product’s lifecycle / evolution path but items belonging also to other product’s lifecycle / evolution path phases as well;
  • Client involvement throughout the whole product’s lifecycle / evolution path – client satisfaction is a function of meeting expectations, therefore, product cluster / portfolio team must establish working client relationships at every product lifecycle / evolution path phase events (ideation, requirements gathering, prototyping, prioritizing, demos, user acceptance tests, and retrospectives);
  • Consideration of integrations and their constraints – complex environment tend to provide for high level of product integration which establishes a certain layer of activities consuming team’s capacity as well as possible wait times to perform works on the other side of integration due to their own backlog priorities and capacity deficits;
  • Consideration of team’s fixed resources – all of the above must be considered and implemented in careful planning of product’s roadmap and various backlogs (unless team and its capacity can be expanded, of course).

GEO product management model

GEO (General Ecosystem Overview) is a product management model that assists Product team in recognizing key elements of product development ecosystem that must be considered across product’s lifecycle. This model also does not provide for specific practices to be performed and tools to be used. However, it helps a lot in understanding the nature of the product, its properties and environment, core product management activities and roles of the Product team and other product stakeholders.

Product

Product is a producer’s way to view something he creates, maintains, and improves to be consumed by others which has following properties:

  • product is used by the client to satisfy his needs;
  • product has a lifespan and specific stages of its lifecycle;
  • product needs to be managed to create benefits for both the client and the producer.

Product management

Product management is concerned with managing products’ lifecycle: creating, maintaining, improving, and liquidating them, to the benefit of and value creation for concerned stakeholders: shareholders of the enterprise, clients, employees, and environment. Management functions in product management include planning, organizing, execution, control, and feedback analysis at every stage of product’s lifecycle by establishing specific protocols (practices, tools and metrics, roles and bodies).

Product lifecycle / evolution path

Product lifecycle differs from product evolution path as it deals less with product change management aspects and includes product liquidation / dismantling stage.

Basic stages of product evolution path correspond to project lifecycle stages and include: determining an unsatisfied need (creating), envisioning a solution (creating), discovering and exploring ways of delivering and sustaining solution by means of a new product or extension of an existing product (creating), developing (creating), testing (creating), and integrating product (creating), product launch (creating), product support (maintaining) and post-launch change management (improving).

Common changes within post-launch change management are: developing new previously non-existent functionality. advancing and improving existing functionality, tuning, major overhauls. As well in SPACE they can be also represented  by “losts” (changes that were not included with the original sprint plan and released increment but which are absolutely necessary for the product to be used by the clients in current circumstances) and “fixes” (changes that were not included with the original sprint plan but which represent errors needing fixing for the product to be used by the clients in the intended and required manner). Each of the changes has their own reasons to arise and are managed and conducted in a different way.

Complex environment

Complex environment is present if:

  • multiple products exist but their development and support are performed by a single large product cluster / portfolio team,
  • each of the products exist in their own stage of product life-cycle and of various importance to the customers,
  • customers might be represented by internal ones, thus where dual monopoly relations between the customer and the team are present,
  • internal customers might complete for the resources of the product cluster / portfolio team, or can provide conflicting requirements,
  • product evolution path is non-linear and can be represented by different types of changes,
  • strict adherence to common agile practices can not be expected, and certain agile constrains have to be loosened.

Since then, an example of where SPACE framework and protocol can be applied is iterative evolution of CFO domain systems (financial planning, budgeting, accounting, reporting).

Work streams

While common agile frameworks deal mostly with the development aspects of product management, SPACE considers every type of activities that need to be performed in order for the product portfolio be managed, product cluster / portfolio team keep engaged with portfolio management, and the clients feel satisfied.

Work streams cover such activities as: people / team management, client relationships management, resource management, risk management, and others as well.

Roles and groups

Key roles and groups are imported and adopted from common agile practices (product owner, team member). SPACE also introduces new roles and bodies.

SPACE groups include:

  • Product cluster / portfolio team is a group responsible for holistic portfolio management. It consists of Cluster / Portfolio owner and Product teams.
  • Product cluster / portfolio apex is an oversight body that is responsible for prioritization items of Portfolio backlog and building current Sprint backlog. This group consists of Cluster / Portfolio owner, Product owners, and Cluster / Portfolio sherpa.
  • Product team is a group responsible for holistic product management. It consists of Product owner and product stage teams.
  • Product apex is an oversight body that is responsible for prioritization items of Product backlog and building current Sprint backlog. Product apex consists of Product owner, [Stage] team leaders, and Product sherpa.
  • Product [Stage] team is a team responsible for a certain stage of the product lifecycle of a certain product. It consists of [stage] team lead and team members.

SPACE roles include:

  • Stakeholder is someone having a specific interest in the product. Stakeholder can be represented by a single person or a group.
  • Client is a special type of stakeholder which has a primary interest with the product since a direct or indirect usage of the product creates value for the customer.
  • Product owner is a key person responsible for managing product’s lifecycle through interaction with client by establishing expectations, gathering requirements, and maintaining ongoing involvement in the course of product development and post-launch change management, and members of the product team by establishing priorities, sequencing work, reviewing results, and improving practices.
  • Sherpa is responsible for conducting and enforcing adherence to practices as they are defined by the SPACE protocol. Key practices where sherpa’s support is required are sprint planning, daily standups, sprint reviews and sprint retrospectives.
  • Team lead is responsible for daily management of team members’ activities. in SPACE protocol team lead and sherpa roles can be shared and performed by the same individual.
  • Team member is responsible for performing activities that deliver results included in sprint backlog.

SPACE assumes a roles matrix that defines responsibilities and functions of each of the roles and detailed for a particular case as its circumstances require. Key responsibilities and functions are provided above within the definition of the roles and groups.

SUN product definition model

SUN (Strategic User eNgagement) is a product definition model that assists Product team in identifying, visualizing, sketching, formulating, and proposing a higher-level understanding of particular product’s purpose, scope, and genesis. This model does not provide for practices to be performed and tools to be used in the course of product development and support.

Practices

Key practices are imported and adopted from common agile practices:

  • Product visioning is a practice aimed at identifying and establishing Product vision. It is performed after determining an unsatisfied need during envisioning a solution phase of product evolution path. Product visioning is performed through interaction of Product / Cluster / Portfolio apex with stakeholders and other participants as well depending on the enterprise traditions. Product revisioning can be performed in the later stages of lifecycle when major changes in stakeholder contexts provide for rethinking a product’s purpose and scope.
  • Product mapping is a practice aimed at formulating Product roadmap. It is performed while discovering ways of delivering and sustaining solution phase of product evolution path. Product mapping is performed by Product apex. Product remapping can be performed in the later stages of lifecycle when major changes in stakeholder contexts provide for rethinking a product’s key milestones.
  • Product sync is a practice aimed at synchronizing visions, roadmaps and backlogs of interrelated Products. It is performed on a regular basis (i.e. quarterly) but in special circumstances can be conducted on a request. Product sync is performed by Cluster / Portfolio apex.

Tools

Key tools are imported and adopted from common agile practices:

  • Product vision clarifies Product’s client and other stakeholders, their needs and value and benefits of the Product in satisfying them, key functions, major stages of Product evolution and expected rollout milestones.
  • Product roadmap provides an overall view of Product’s evolution calendar, detailing actions that need to be taken to deliver on rollout milestones and their timeline.

JUPITER requirements capture model

JUPITER (Reverse Engineering To Improve Product User’s Journey, abbreviated backwards) is a requirements capture model that assists Product team in collaborating with end-users in identification and gathering initial requirements and, later, requirements for changes to be implemented within the product. This model does not provide for transforming customer-developed and formulated wants to Product and Sprint backlog items. However, it helps a lot in establishing, clarification, and verbalizing users’ expectation by the users themselves.

Practices

Requirements capturing is a practice aimed at gathering Initial (change) requirements to be implemented within the product. It is performed throughout the product’s lifecycle after Product vision and Product roadmap are complete. Requirement capturing is performed through interaction of Product / Cluster / Portfolio apex with stakeholders and other participants as well depending on the enterprise traditions.

For product properties (initial and their later changes) to be desired wholeheartedly, performed optimally, and captured perfectly, they must be assessed whether they are:

  • relevant – every product property (initial and changing) must address specific parts of the product

At the user’s level certain product components matter, while other product components stay irrelevant as they form the inner working of the product with which the user might not interact and, therefore, have no concerns regarding them. It would be almost precise to define data model, business rules, core functionality, and UI/UX as key product components that might matter and be mentioned by the user in addressing change. Definition of Done is stated at this point of product change assessment.

  • initiated – every product property must have a person who is the driving force for introducing it

While product users are rich in types, two key dimensions determine the level of user’s influence over product property definition process: type of usage (active / passive) and seniority level (which may come in different flavors).

  • valuable – every product property must demonstrate specific and measurable benefits

Product properties can bring various business or personal benefits for the user: revenue growth, efficiency improvement / resource optimization, mitigating risk, overall better user experience (aesthetical or performance). Business value is stated at this point of product property assessment.

  • scalable – most product properties must be addressed assuming regular use of property outcome

Product properties that would be implemented for a single use are not generally welcomed unless they come with a powerful business or user case.

  • ecological – every product property must take in account side effects caused by it
  • approved – every product property must be confirmed by a defined authority, person or body
  • prioritized – every product property must be assigned its importance and urgency

As described above, importance and significance of the property achievement are determined by its complexity: initial development, tuning, improvement, advancement, development, and overhaul changes as they are defined in the SPACE framework. Urgency of the product property achievement is determined by the timeliness of property achievement: current (coming sprint), forthcoming, fixes, and losts.

  • defined – every product property must be thought out and clearly described by the user

For a product property to be defined, key questions must be addressed by the user:

      • What is the essence of the property requested?
      • What must be done in the first place?
      • What would be impacted by the property?
      • What must be done to support the property within and beyond the product?
      • What are specifics of requirements implementation (e.g. spacial and time segmentation of property achievement effect)?

After addressing these questions a JUPITER statement is formulated:

As a user, I want <benefits> [Business value statement], which come <in a certain form> [Definition of Done statement], that is achieved by <taking specific actions> [Reverse Customer Journey Map for functionality and / or UI/UX properties or data model and / or business rules properties].

  • efficient – most product properties must provide positive economic value
  • resourced – every product property must be backed by adequate resources to implement it

Except for the last two product property qualities, the rest of them are fundamental for user requirements capture. By addressing them, users form the initial (change) requirements that are subsequently adapted, backlogged, estimated, prioritized, and executed by the product team.

Tools

User’s Initial (change) requirements consists of:

  • JUPITER statement
  • description of product property parameters (driving force, type of change and urgency of implementation, scale of use, relevant product components and environment domains affected)
  • initial change requirement approval.

VENUS backlog building model

VENUS (Validating, Estimating, and Nesting User Stories) is a Product backlog building model that assists Product team in transforming customer-developed and formulated wants to Product backlog items. This model does not provide for with particular practices to be performed and tools to be used in the course of product development and support. However, it helps a lot in shaping users’ expectations and developing a pipeline of work for the Product team.

Practices

Product backlog building is a practice aimed at transforming Initial (change) requirements to Product backlog items. It is performed throughout the product’s lifecycle upon collection of Initial (change) requirements. Requirement capturing is performed through interaction of Product / Cluster / Portfolio apex with stakeholders and other members of the Product team.

Product backlog building involves:

  • validation of requirements – which assumes assessment of requirement’s clarity and completeness, technical feasibility, compliance to Product vision, availability of Product team’s resources and skills to address requirement
  • estimation of cost to implement requirements – which assumes overall analysis of expected Product team’s workload in addressing requirement and analysis of requirement implementation TCO
  • nesting user stories – which relates to transforming requirements into units of work (epics, features, user stories) to be placed with the the Product backlog to be performed by the Product team

Within SPACE framework units of work are defined in the following manner:

  • epic describes volume of work performed over 1 sprint in relation to a products’ component
  • feature describes volume of work performed over 1 sprint in relation to an aspect of a product’s component; can be independent or detailing a higher-level epic
  • user story is a basic unit of work placed with the Product backlog that describes volume of work performed within 1 sprint in relation to an instance of an aspect of a product’s component

Combined with proposed within SPACE product lifecycle model following units of work exist:

Tools

Key tool is imported and adopted from common agile practices:

  • Product backlog breaks down high-level requirements of the Product vision and activities of the Product roadmap and transforms customer-specified product properties requirements (initial and change) into the list of manageable and operational activities of the Product team (epics, features, and user stories).

MARS sprint management model

MARS (Managing to Achieve Results of the Sprint) is a sprint management model that provides product team with particular practices to be performed and tools to be used in the course of product development and support.

Practices

Key practices are imported and adopted from common agile practices:

  • Sprint planning is a practice aimed at building Sprint backlog by selecting priority items form Product backlog. It also helps to check whether the Product team activities and results comply with Product vision and Product roadmap and whether adjusting actions need to be taken. It is performed on a regular basis at the start of the sprint at all stages of product lifecycle. Sprint planning is performed by Product apex and is conducted by Sherpa.
  • Daily standups is a practice aimed at reminding the team of Sprint goals and priorities, keeping track of tasks to be performed and results to be achieved during the day, and researching of risks and problems arising in the course of the Sprint. They are performed on a daily basis during the sprint. Daily standups are performed by Product team and are conducted by Sherpa. If the Sprint lasts longer than 2 weeks, Weekly standups can be introduced.
  • Sprint reviews is a practice aimed at demonstrating stakeholders and, specifically, clients the results of the Sprint, while gathering feedback and adding adjusting and new items to the Product backlog that arise during the review. Sprint reviews are performed on a regular basis at the end of the sprint at all stages of product lifecycle. Sprint reviews are performed by Product team with deep stakeholder involvement and are conducted by Sherpa.
  • Sprint retrospectives is a practice aimed at adjusting Product team’s management and technical practices through emphasizing better working and optimizing less efficient ones. Sprint retrospectives are performed on a regular basis at the end of the sprint at all stages of product lifecycle. Sprint retrospectives are performed by Product team and are conducted by Sherpa.

Tools

Key tools are imported and adopted from common agile practices:

  • Sprint backlog is a list of prioritized items selected from the Product backlog during the Sprint planning to be executed during the Sprint.
  • Daily backlog is a list of prioritized items selected from the Sprint backlog during the Daily standup to be executed during the day. If the Sprint lasts longer than 2 weeks, Weekly backlog can be introduced.

In addition to common agile tools following tools are introduced:

  • Closing memo is a list of adjustments to Product team’s protocol that were identified by the Product team upon completion of the sprint during the Sprint retrospectives to improve Product team’s practices and performance.
  • Black book is a detailed description of total disasters that happened within the Product team, reasons of failure, and measures that had to be taken for mentioned events not to develop. Black book’s function is to remind the Product team of systemic issues that should be addressed, both relating to the cases described and hidden ones.