Build it to share!


The Masterplan is a conceptual model that harmonises business goals with roles and activities within an organisation, to help it pursue the share and reuse of data with open licenses. Masterplan - Build it to share! is a guide for the implementation of this target into traditional business model elements –such as values, segments and revenue streams– promoting a strategic use of opendata.


opensensorsdata logo

Fork me on Github

Masterplan is also available as ebook

Copertina Masterplan

Masterplan in italiano! Masterplan in italiano!


  • Firms, to help design adequate activities in support of open business models development. These are models used by companies and ventures in order systematically create and capture values through collaboration between external partners and internal teams.
  • Government agencies, to promote reliable methods that help create cross-functional projects and manage their teamwork. These usually comprise different expertise that act as hub for the production and sharing of data (for different purpose, such as promotional or normative one).
  • Single expert, to increase her ability to cooperate into an harmonised and supportive organisational environment.


The Building Site is where the project comes to be realized. The project is the result of an incremental model; it starts with an executive order that defines the request. Strategic planning of operational requirements are entrusted to the designer, which is osd.

  1. Project is the scheme within which knowledge, people and expertise are represented. The scheme should always be designed as to meet the executive’s goals.

  2. Building Site is the realization of a data reuse project.

  3. Executive is the client, or the businessperson, who pulls the request.

  4. Designer or strategist, manages and organizes the operational requirements at the basis of the Project.

  5. Site Engineer (Product Owner) compiles and monitors the activities in progress (backlog); she evaluates the consistency, together with the Site Manager, between the backlog and the executive’s request.

  6. Site Manager (Scrum Master) check the resources, validates the workflow’s progress and optimizes the activities of team leaders.

  7. Team Leader selects the appropriate databases and data sources and coordinates the datahat squad.

  8. Datahats the data, agents that are activated or aggregated by the roles aforementioned.


  • Product Owner is the technical term for The Site Engineer; she keeps the workflow focused on vision and values (as well as keeping the backlog up and running).

  • Scrum Master is the technical term for The Site Manager; helps the team and the team leaders to manage obstacles that emerge while the workflow progress.

  • Activity that which is executed for the purpose of managing the Project and keep it clean and efficient.

  • Backlog it is defined by the site engineer (Product Owner); is the set of user’s stories that are planned and developed by the team leaders in order to complete each part of the project.

  • User Stories a user story is a part of the Project and it is defined in terms of how long it takes and how it is accomplished. A user story should fit INVESTrequirements:

    • Independent, should not depend on other user stories.
    • Negotiable, if the user story has been already completed it must be converted as input for other user stories.
    • Valuable, it must produce value for some other roles in the project.
    • Estimable, it must be estimated in terms of time and value.
    • Small, it must be possible to define the who/what/why of the story (action, segment, result).
    • Testable, it must be possible to test and verify the user story.
  • Tasks are the elements of the user story; they should be clearly reported in the backlog. A task is made of:

    1. the author or owner or the task;
    2. the goal:

      • how
      • what
    3. time-frame
    4. value (defined via the Planning Poker);
  • Planning poker team leaders and site managers assign a score (1, 3, 5, 8, 13) to each user story and submit the proposal to the site engineer.

  • MVP the Minimum Viable Product is the goal to which every each user story should comply: it should be a minimal functional outcome. The scope of this outcome is minimal in the sense that it represents the essential elements that define the product. Why it is important to state the user story in terms of MVP? This is because, usually, reduce burdensome activities by keeping development’s complexity at the minimum required to accomplish the goal.

  • PDCA Cycle PDCA is the acronyms for these recursive phases:

    1. Plan
    2. Do
    3. Check
    4. Act
  • Sprints Sprints, or “time boxes”, have fixed time-frame. A sprint is technically a single PDCA cycle inside the project.

  • Sprint Retrospective it is the sprint self-assessment accomplished by team leaders with the help of the Site Manager; this step correspond to phase (3) of PDCA Cycle. Sprint retrospective is composed by five questions. The corresponding answers are used in the (4) phase of PDCA Cycle:

    • Are you satisfied by your user stories? (1 to 5)
    • Were the connections among the team expertise useful? (1 to 5)
    • How quickly teams spotted errors? (1 to 5)
    • Were there burdens in the user story –like, unsolved issues, problems in detecting mistakes and the like? (1 to 5)
    • Was the stipulated time-frame for the user story appropriate? (1 to 5)


The architectures are the fundamental structures of the building site. The overall architecture is composed of different levels, one on top of the other; each level instantiates roles and activities and requires appropriate safety measures. According to a Top-Down progression we have:

  1. LEVEL 0

    • Roles: Executive - Designer.

    • Description: it is the level zero, where the evaluation of the project takes place. Executive and designers discuss the building site with the site engineer.

    • Activities:

      1. Discuss the requests.
      2. Define the priorities.
      3. Stipulate the MVP.
      4. Set an appropriate time-frame.
  2. LEVEL 1

    • Roles: Executive - Site Engineer.

    • Description: it is the very first level, where the executive pulls the request and the site engineer works out the appropriate requirements accordingly.

    • Activities:

      1. Individuate the requirements.
      2. Compose the backlog.
      3. Select the site managers.
      4. Assign the necessary resources
      5. Define the time-frames.
  3. LEVEL 2

    • Roles: Site Engineer - Site Manager

    • Description: it is the second level, where the site engineer coordinate and harmonize the requirements and the site manager plans and schedules the activities.

    • Activities:

      1. Verify the resources.
      2. Prepare the working groups.
      3. Establish the necessary verification procedures.
      4. Arrange the sprint cycles.
  4. LEVEL 3

    • Roles: Site manager - Team Leader

    • Description: it is the third level, where the site manager establishes the tasks and the team leaders select the pertinent teams’ activities.

    • Activities:

      1. Plan sprints’ activities.
      2. Build up user stories (the overall tasks that constitute the activities).
      3. Planning Poker (assignment of value points).
  5. LEVEL 4

    • Roles: Team Leader - Team Leader

    • Description: it is the fourth level, where team leaders coordinate teams and define hierarchies.

    • Activities:

      1. Check any overlapping datahat flow (that is, if more that one team leader use same datahat squad).
      2. Check consistency in the assignment of planning poker’s values.
      3. Determine the expertise.
  6. LEVEL 5

    • Roles: Team Leader - DataHat squad

    • Description: is the ground level, where the team leaders select and monitor its datahat squad.

    • Activities:

      1. Access to datahat.
      2. Use of datahat.
      3. Levels of automation.
      4. Typologies of datahat.


The safety measures are the set of prescriptions and preventions needed to ensure the plasticity and robustness of the building site.

Prescriptions are the conditions by which the building site and its workers can be kept operative, safe and sound.

Preventions are the checks and tests necessary to exploit and manage errors and avoid perils for both the project and the well-being (mental and physical) of workers.


1. Roles

2. Datahats

3. User Stories

4. Tasks

5. Communication time-frame

6. Plan

7. Do

8. Check

9. Apply


An accurate definition of the roles is crucial for a successful execution the project. Each site manager and each team leader has two first important duties: select its datahat squad and program their tasks inside one or more user stories. The site engineer is in charge of monitoring these low-level activities and harmonizes their performance. The executive and the designer should carefully listen to every hint or issues the site engineer draw their attention to. This is a reality-check and serves the purpose of validating the feasibility of the pulled request throught organizational feedback.

This section is of general interest and pertains to every level of the architecture.


  1. The executive should carefully evaluate each request before the cycle begins.
  2. The site engineer should focus on compiling and monitoring the activities in progress. She is in charge of the backlog, that’s her major workspace; she should constantly evaluate the consistency between the activities and project’s goals, modeled in the MVP. Finally she is in charge of reporting every communication from the site manager to the executive.
  3. The site manager is in charge of resources’ management. Her major role is to keep an eye on workflow’s progress. When it is needed, she must optimize activities of team leaders.
  4. No lazy datahat allowed in the building site. Datahat should always have a role in the building process. If they don’t, then revision of their role is needed.


  1. Has the project been divided into user stories that have a clear time-frame?
  2. Is the executive autonomous in her choices?
  3. Is the site engineer internal or external to the executive’s organizational structure?
  4. Is the site manager qualified to individuate, describe and suggest upgrade to the project based on team leaders feedbacks?
  5. Do datahat belongs to more than one team leader?


Remember, if there is a building site, there is always someone monitoring the workers. Sharing your datahats is the best business card for every professional involved in the building process. Their quality, and the quality of their work, depends on who produce, select and leads them. That is, on team leaders.

This section is of particular interest to Team Leaders and pertains to Level 4 (Team Leaders-Team Leaders) and Level 5 (Team Leaders-Datahats)


  1. Remember that an activity is the minimal manufacturing element of the building site.
  2. Remember that a user story is the minimal manufacturing unit of the project.
  3. A squad of datahat should be clearly defined and must be autonomous in its activity.
  4. Each activity assigned to a datahat squad should always be brought to completion.
  5. Each activity assigned to a datahat, when accomplished, can provide the basis for another activity performed by the same, or another, datahat squad.


  1. Is it possible to distinguish datahats from the activities they perform?
  2. Does the datahat squad perform her activity in autonomy or they cooperate with other squads?
  3. Does the datahat squad already perform some other activities outside of my control?
  4. Are the datahats’ activities well-documented? Can team leaders easily explain what is the purpose of their work inside the general structure of the building site?
  5. How many activities my datahat squad –and their tasks– can support?


The making of a user story involves team leaders and their ability to select and document the tasks that are relevant for the execution of the project. The attribution of a score, based on planning poker methodology, should always be based on a negotiation between team leaders and the site manager. The result of this negotiation must always be clear and unanimous.

This section is of particular interest to Team Leaders, Site Managers and Site Engineers. It pertains to Level 3 (Site Managers-Team Leaders) and Level 2 (Site Engineers-Site Managers)


  1. The site manager should help each team leader pick the right user story, the one they think they can bear and accomplished without excessive stress or extra work.
  2. The site manager coordinates with the site engineer to harmonize and distribute the workload (activities) appropriately across all the team leaders.
  3. The harmonization role performed by the site manager together with the site engineer cannot be accomplished if the goal, around which each user story should be modeled, is not clearly defined.


  1. Is the communication of goals clear and documentation accessible to everyone?
  2. Is the documentation beneficial for solving problems that emerge in course of activity?
  3. Are the executive’s requests negotiable or they are rigidly tied to some specific activity?
  4. Can team leaders account for all the activities negotiated with the site manager?


Each team leader defines and selects the tasks for her datahat squad. Tasks are the elements that compose a user story. Each task should be kept simple, as to minimize confusion and allow error detection. Each tasks should be always be assigned on the basis of a previously defined goal.

This section is of particular interest to Team Leaders and pertains to Level 4 (Team Leaders-Team Leaders) and Level 5 (Team Leaders-Datahats).


  1. The efficiency of team leaders can be measured by the number of issues or errors they can spot and by their problem-solving rate.
  2. Accounting for a specific task in the smaller time-frame possible is the easiest way to verify the task’s consistency within the user story.
  3. Each task must be accountable for every role involved in the building process.


  1. Is the drive for a task compatible with the goals of the project?
  2. Is the user stories’ list accessible to everyone?
  3. Are people producing the documentation to help understand their tasks and roles?
  4. Are user stories supplied with the necessary documentation?
  5. Is the history accessible to those who want to check for duplication or past errors?


Each site manager should be aware that more team leaders work in the building site, more time will be spent to curate communication of tasks and users stories. Documentation can assist in the quest, if and only if the documentation is clear, concise and easy to access. The documentation plays a crucial role in the economy of organization. Communication channels can be designed using the standard formula:

communication channels = n(n-1)/2

where n stands for number of people involved.

This section is of particular interest to Team Leaders and Site Managers. It pertains to Level 3 (Site Managers-Team Leaders).


  1. The site manager must individuate wastes or obstacles in the communication process.
  2. Experts should be coordinated on the basis of their actual contribution to the project, rather than merely on their expertise.
  3. The site manager discusses and arranges one priority at a time with each team leader.
  4. The documentation must be effective in reducing the number of meetings and their duration.
  5. Documentation is needed in order to check and improve the deployment of user stories in sprints’ retrospective.


  1. What did we accomplish so far? What’s next in line? Did we run into problems? If yes, are they now adequately documented?
  2. Did each team leader accomplished her role?
  3. Are there tasks that require to be managed by more than one team leader?
  4. Are team leaders actively cooperating together?
  5. Are obstacles seen as challenges or as burdens?


The first plan should address the realization of the MVP. Requirements are functional to the MVP and shoud be implemented accordignly. To plan means to associate a user story with its goal; this latter must be coherent with the overall project setup and clearly conveyable to each member. User stories are the results of tasks chosen for their effective contribution to the project’s goals.

This section is of particular interest to Team Leaders and pertains to Level 4 (Team Leaders-Team Leaders) and Level 5 (Team Leaders-Datahats).


  1. Team leaders assign points (1,3,5,8,13) to each user story using planning poker.
  2. Sprint’s duration is the time-frame that defines the start and end point of each development cycle.
  3. The set of all sprints determine the overall building site duration and effectiveness.
  4. The user story can be closed only when all tasks are completed.


  1. Among team leaders, is there agreement on the value of all the user stories?
  2. Does composition of the user stories only comprises the minimum elements required?
  3. Among team leaders, is there agreement about the duration of the sprints?
  4. Is the documentation of one user story of any use to the composition of tasks for other user stories?
  5. Do team leaders too often work overtime to close a user story?


The execution of tasks and the work of each datahat squad should always generate value for both the professionals that lead them and other professionals that take the final product of a user story as a starting point for their own activity. Each role in the building site should always be able to reuse user stories or tasks’ outcome as much as possible, for herself or for other member. Reuse is made easier if a clear documentation is available. Remember, errors are inevitable parts of the building process. The challenge is to exploit them, possibly, in the shortest period of time and with the minimum effort.

This section is of general interest and pertains to every level of the architecture.


  1. The site engineer, who is in charge of the backlog, should take as input the recommendation of site manager and team leaders; she should harmonize the activity inside the backlog compatibly with sprints’ duration.
  2. Datahat squads are effective if team leaders are knowledgeable about where they are and what are their goals.
  3. Team leaders must always document their job to make it easier for anyone else to reuse their production.
  4. The production coincides with the progress of a user story.


  1. Is there any anxiety or concern regarding the completion of a user story?
  2. Are team leaders supportive to one another?
  3. Are team leaders free to talk straight to their site manager?
  4. Are site managers effective in making the production process more fluid and less stressful?
  5. Do site engineers always proceed with verification of workflow’s progress?


Any verification applies on tasks and their output. To improve means to introduce the right correctives that help the site manager to redesign the same activity and obtain the same result in less time and with less stress. Again, errors are constructive parts of production cycle.

This section is of particular interest to Team Leaders, Site Managers and Site Engineers. It pertains to Level 3 (Site Managers-Team Leaders) and Level 2 (Site Engineers-Site Managers).


  1. An healthy and flexible workflow depends on site manager’s ability to monitor ongoing tasks and user stories.
  2. Fix the machine, not the people. Obstacles are often rooted in misunderstanding at the negotiation level; avoid blaming people for that; instead, fix the negotiation process.
  3. The Site Manager prepares the list of obstacles and, together with team leaders, negotiates priorities and solutions.
  4. There are no hierarchical relations between site managers and team leaders; they cooperate side by side.
  5. There are no tasks relieved from obstacles.
  6. Boredom and frustration are the worst obstacles for the project.


  1. Do team leaders have enough time scheduled to think critically about their tasks and how to operate?
  2. Is the site manager able to negotiate and attain consensus about what is considered to be an obstacle?
  3. Do obstacles consist in task’s duplication or in conflicting tasks?
  4. Are all team leaders aware of what user stories are arranged?
  5. Does the site engineer takes into consideration the list of obstacles when compiling the backlog?
  6. Can an obstacle be solved scheduling an appropriate task?


The result of every verification phase is an input for further sprints. Application and planning are closely connected in that the output of the former is taken to be the input of the latter. Like the PDCA, the sprint works in cycle; it works by exploiting errors and improve the effectiveness of the workflow.

This section is of general interest and pertains to every level of the architecture.


  1. The solution to a problem should be satisfactory for each role affected by the problem.
  2. Implemented upgrades should always be documented so that can be reused to improve the responsiveness of all workers in the building site. The documentation should be seen as an handbook for further possible upgrades.
  3. The site managers should not impose an upgrade; they should always negotiate any change in schedule with team leaders.
  4. Errors are parts of the building process. They shouldn’t be chancy; rather, they should be a matter of conscious organizational management.
  5. Failure to document an issue, or a problem, might results in a more serious failure of the building site and, as a consequence, of the project.


  1. Is the documentation relative to an upgrade that request specific expertise to be solved?
  2. Can site engineers reuse one upgrade to improve the work of other team leaders?
  3. Can site managers evaluate how much team leaders are satisfied with their workload?


Copertina Masterplan

Masterplan - Build it to share!

can be downloaded

epub every ereader

mobi kindle

If you like the project and want to support there is an Amazon edition you can buy for just 0.99$.