This website uses cookies to manage authentication, navigation, and other functions. By using our website, you agree that we can place these types of cookies on your device.

View e-Privacy Directive Documents

You have declined cookies. This decision can be reversed.

You have allowed cookies to be placed on your computer. This decision can be reversed.


sdPP Element Description

Scrum is an agile method of software development. Rather than a full process or methodology, is a framework. So instead of providing a complete and detailed description of how everything has to be done in the project, many parts are left in the hands of the software development team. This is done because the team will know the best way to solve the problem faced. This is the reason why, for example, a sprint planning meeting is described in terms of desired outcomes (a commitment to the number of features to be developed in the next sprint) rather than a set of entry criteria, task definitions, validation criteria, and exit criteria (ETVX) as presented in most methodologies.

Scrum is based on self-organization with MFD. In the scrum team there is a team leader in general that decides which person will do the task or how a problem is solved. These are issues that are decided by the team as a whole.

These agile development teams rely on two individuals: Scrum Master and Product Owner. The Scrum Master can be considered as a coach for the team, helping team members to use the Scrum framework to perform at their highest level. The product owner represents the business, customers or users and guides the team to build the right product.

Scrum projects moving in a series of sprints, which are fixed length iterations of not more than one month. At the start of a sprint, the team members are committed to producing a number of features that are listed in the Product Backlog. At the end of the sprint, these functions are carried out - are coded, tested and integrated into the evolving product or system. At the end of the sprint a review takes place during which the team demonstrates the new functionality to the product owner and other interested parties to provide information that could influence the next sprint.

In the sdPP Model the description is a textual field that provides a short explanation of its use and application, as well as the methodology, reference framework or best practices the sdPP came from.


sdPP Element Description

In the sdPP Model a Work Breakdown Structure (WBS) is used to organize the methodology activities. It is an organizational view of the activities proposed by the sdPP that helps the project manager understand the hierarchy between the activities


sdPP Element Workflow

The workflow, in the sdPP model, indicate the recommended sequence to perform the activities described in the WBS. The UML activity diagram was adopted to define the workflow between the activities. The workflow guides the project manager through the activities indicating the order in which the activities should be carried out


sdPP Element Product Flow

The sdPP model uses the "productflow" field, for indicating how the products flow between activities. Typically an activity has a set of input products required to execute it and a set of output products that are the result of the activity execution. These products flow between the activities following the workflow.

To Dos

sdPP Element Description

To Dos:

  • Size of each team from 5 to 9 people.
  • Dedication of the team full time.
  • Meetings begin promptly on time.
  • They punish people who are late to a meeting.
  • Daily meetings are held in the same location and same time every day.
  • Planning meetings will last no longer than 8 hours.
  • It should minimize the number of goals / requirements that the team works simultaneously.
  • requirements will be completed first to give more value to the customer.
  • The team should have some criteria agreed on the implementation process of the task.
  • Requirements not be considered completed another requirement planning.
  • For Sprint planning is necessary to have available working capacity of the team.
  • The organization has some potential resources to carry out the sprint.
  • Whenever possible, the product owner must have worked previously with the team already. Thus its previous estimate of how much of the product backlog may develop in the sprint will be quite tight.
  • The team has a knowledge of the technologies, business and product enough to make estimates based on "expert judgment", and to understand the concepts of business that exposes the product owner.
  • Provide the necessary licenses to work on computers.
  • Provide rooms prepared for working with agile methodologies.

Not to Dos:

  • Laying the daily meeting attendees.
  • Change the objectives / requirements of the current iteration.
  • Solve problems in daily meetings.
  • Show the customer requirements that are not finalized.
  • The duration of a daily meeting did not exceed 15 min.
  • The Daily Scrum is not for problem solving and team members only, Scrum Master and Product Owner can talk.
In the sdPP model, a set of “to-dos” is given with recommendations based on the best practices and lessons learned. This “to-dos” list tries to establish the tacit knowledge based on experience about the methodologies, reference frameworks and best practices. A “to-do” is neither an activity nor a part of the workflow (i.e. “work in pairs” cannot be an activity).


sdPP Element Requirements

  • Fixed period of 30 days to develop a deliverable.
  • The Sprints include design, coding, testing and documentation.
  • Daily status meeting 15 minutes in which the team stands in a circle.
  • The Scrum team should be self-organized, multidisciplinary without roles, comprising 5 to 9 people, committed to working with the authority to do what is necessary to meet the objectives.
  • Modeling and analysis can not be done separately.
  • Do not focus on functionality.
  • The complete models are useless: We have to negotiate and reason given the inconsistencies.
  • Model the environment, consider the inconsistencies, incompleteness and changes.
  • Expands the repertoire of techniques.
  • Build richer models.
  • Understand the impact of architectural decisions.
  • Reuse models.
  • Specialist multidisciplinary.
The sdPP model defines a set of requirements that the project manager should be able to satisfy in order to apply the solution given by the pattern. These requirements have nothing in common with software requirements; they define the preconditions to be met in order to apply the solution proposed by sdPP.


sdPP Element Description
Reliable backup: NA Online Update: NA
Data communications: NA Complex interface: 1
Distributed functions: NA Complex processing: 1
Perfomance: 4 Reusability: 3
Heavily used configuration: 3 Installation ease: NA
Online data entry: NA Multiple sites: 0
Operational ease: 4 Facilitate change: 5
The sdPP model classify the models with a set of metadatas. We have defined fourteen quantitative numeric fields with values from 0 to 5. Those fourteen fields describe what kind of software development projects sdPP is appropriate for.


sdPP Element Risks

Implementing Scrum comes with changes. These changes are not only related to the software development department, but will affect everyone in the company, including management. Job descriptions will change, and the corporate structure and culture. Changes and challenges in adopting Scrum are:

  • There will be turnover.
  • There will be conflicts.
  • The product management work will change and be more difficult.
  • Engineering is responsible for the quality.
  • Compensation policies have to change.
  • Work will change.
  • The primary responsibility of government will command a servant leadership.
  • Management rotation will occur.

Scrum makes employees leave the company: At first glance this sounds very dramatic, but it really is not. Scrum is created through transparency and nobody can hide behind the supposed mistakes of others. Through the observation of the "time box" tasks within the team and transparency with respect to when something needs to be delivered, statements like: "... I've been waiting for this or that ..., or ... I had to do so many things for the customer who simply did not get ... "lose its foundation. Yes, the introduction and implementation of Scrum can lead to the fact that some employees and the manager did not feel comfortable in his company and leave because not everyone likes the changes Scrum.

Scrum creates conflicts: Yes, because Scrum brings out problems of the company, and management teams. In some companies unfortunately not try to expose problems and therefore do not remove them. Scrum that can not function in this way must be very clear. This misuse is why statements like "Scrum is chaotic", or "Scrum does not work for us." The spectrum of potential conflicts that can occur through the introduction of Scrum is versatile. It starts with directors who like transparency in development, but do not want to share their views or who think that the rules are only for others. Project leaders must first classic take on the role they have to take in the scrum. In addition, a company needs demand customer collaboration.

The sdPP model defines a set of risks the project manager would assume if the solution were applied. These risks warn the project manager about possible problems in the project execution. The project manager must understand these risks to try and avoid them.
Copyright © 2017 Diego Martín. All Rights Reserved.