Our Agile Development
Methodology
In traditional developments, when the requirements are not perfectly defined at a functional and technical level, projects are estimated with a certain margin of error, which is not desirable for several reasons:
- The probability of deviation in times and costs is very high.
- There is a high risk of overestimating or underestimating the Project, jeopardising the finances of the client or the consultancy.
- To fulfil the plan, the necessary flexibility to changes in requirements will not be maintained, which may lead to a final product that does not meet the requirements that the market needs to meet.
- A wear and tear on the team occurs due to constant discussions of scope, times and costs.
Therefore, in order to carry out a development that maintains flexibility in the requirements but without affecting the costs of the project beyond what is effectively necessary, we implement the following agile methodology, based on Scrum.
Project life cycle
Our goal is to deliver a quality product as soon as possible making an evolutionary development flexible to changes, so we use SCRUM implementing the process as follows:
The client, as the main reference and stakeholder, must provide the Product Owner, with all the necessary information (in the form of correctly defined user stories) so that we can transform those user stories into product backlogs that can be processed by the team, which are nothing other than the functionalities of the system to develop correctly defined. In case of not having such a definition level, we will provide support to the client to create the aforementioned technical backlog*.
* The “technical backlog” is not a SCRUM document itself, but an internal document of ours that provides the sufficient level of detail to define the architecture and the technical-functional scope of the product to be developed. The diagrams, structures or definitions it contains will depend on the nature of each particular system. The objective is not to serve as the final documentation of the project, but rather to provide a precise and sufficient technical definition to make an estimate with a low margin of deviation.
Each of these product backlogs will be transformed into sprint backlogs (specific functionalities to be developed in an iteration) in the Planning meeting, which takes place immediately before the start of each sprint. During that, the main stakeholder or customer reference, together with product owner and the scrum team, define what will be built in the next iteration. The iterations could be both weekly and biweekly, depending on various factors.
During that time, various activities are carried out daily in a cyclical and repetitive manner. One of the main ones consists of the process of refinement or Refinement meeting of the product backlogs so that they have all the necessary information so that the team can include it in the next sprint (not in the current sprint). In this ceremony the participation of the client is necessary.
An internal daily meeting is held. In order to provide transparency, we propose to the client to hold a weekly meeting to have a point of contact and progress control.
Each completed iteration produces a more refined deliverable than the previous iteration. This process is repeated until the agreed development is completed. In the Sprint Review, at the close of each sprint, that deliverable is presented to the client.
During the course of the project, the Agile.MyTaskPanel software is used as an online project management tool to provide visibility throughout its development cycle. A user will be given to the client so that they can follow the status of the project on a daily basis.
Index
Main features
Multidisciplinary and
Self-Organized Teams
Agile Development
Increases
Team Motivation
Client Integrated
In The Team
Quick Feedback Of The
Product In Development
Flexibility In Incorporating
Changes
Reduction In The Final
Delivery Time Of The Project
- Independent: the user story must be self-explanatory; it must not depend on other user stories.
- Negotiable: to avoid including too much detail, so that user stories are flexible and can be modified.
- Valuable: user stories should bring some value to the end user.
- Estimable: you must be able to estimate the resources needed to complete each user story.
- Scalable: make user stories simple, so they can be commissioned and prioritized.
- Testable: explain the verification and approval criteria, so that the team knows and applies them when a story is complete.
Checklist to accept a User Story
- Does the user story contain all three “Ws”?
- Does it meet INVEST criteria?
- Are the acceptance criteria clearly defined?
Example
It is a very simple case, but I think it clarifies the concepts explained above.
As a start-up founder, I want to be able to create an account on the XYZ site, so that I can join the community of investors and mentors.
Criteria of acceptance
- To be able to create an account manually (by completing the sign-up form)
- Create an account via Google
- Create an account via Facebook
Product Backlogs
It is nothing other than user stories transformed into a prioritized list of deliverables that must be implemented through the development process. A product backlog item (PBI) is a single item within that list. It must contain all the necessary information so that the team can eventually include it within an iteration (transformed into a sprint backlog).
It might at first seems like it is the same as a user story, but it is not. The latter goes beyond a particular change or requirement. It puts the user at the center and describes a feature of the system from his point of view.
Sprint Backlog
During the Planning meeting, the PBIs that will be part of the next sprint are selected and divided into one or more sprint backlog item (SBI). Being simplistic, it is nothing more than a PBI within a sprint. Actually, it’s a bit more, because that SBI needs to have a higher level of detail. Furthermore, one PBI can give rise to several different SBIs.
They are nothing more than meetings with different participants and designed for very specific purposes. To be clear, not everything that takes place in these meetings will be discussed, but the purpose of the meetings will be made clear.
Planning
In this meeting, which occurs prior to the start of a sprint, the PBI that will be developed in it are selected and transformed into SBI.
Refinement
In this meeting, which takes place during the first days of the start of an iteration, the following PBIs to be developed in the next sprint (not the current one) are analysed and refined. That is, they are lowered to a sufficient level of detail in order to be developed later.
Daily
This daily meeting is made to see what was done the day before, what will be done on the current day and the impediments that may exist.
Review
In this meeting, which takes place after the completion of an iteration, the result of the iteration is presented to the client.
