Development process manifest

The development process becomes more important every day and applies to more areas of everyday life, so leaving it to chance would be like planning a fail. The order and importance of the process, each stage and the revision of them, makes each product that we believe is better adapted to the needs of our customers.

At Southern Code we aim at achieving quality not only of the products and services we provide but also of the process itself, we are convinced both are mutually dependent. The workflow we’ re using is called “Scrum”, but with a few small adaptations and this variation is known as “Scrumban”.

We have worked with different approaches and we’re now confident that our current workflow helps every team member to understand what and how each task should be done and also to have a wider vision of the project, which helps to feel more connected to the entire process.  

However nothing is perfect, and the process can be improved, so we need to be sure the process is constantly reviewed. The main idea is to split the project into smaller tasks and then assign them to sprints (a time period of 2 weeks usually). This will be explained in more detail in the “Workflow” section.


Like in a puzzle each piece (in this case role) is important to achieve the proposed goals. No one is indispensable, but the union of all of them makes a successful product.

  • Product Owner: This member is the link between the stakeholders and the development team. It defines the product in customer-centric terms (called “user stories”) and handles the product backlog (group of tasks that need to be done) and prioritizes them based on importance and dependencies.
  • Development team: Responsible for analyzing, coding, testing and deploying each story assigned to the sprint.The development team can be divided into smaller teams according to their specific functions. These are UX/UI, Frontend development, Backend development, QA and Devops. More details about each of these teams in the technical section. 
  • Scrum master: who facilitated scrum, responsible for removing impediments to the ability of the team members to deliver product goals and deliverables. It isn’t a traditional team leader or project manager but acts as a buffer between the team and any distracting influences.
  • Technical leader: Responsible of defining all tech related matters such as technologies to be used in each part of the product, solving architecture issues and acting as a buffer between the customer-centric user stories and the technical requirements of each story whenever is needed.


And now? Where do we start?

The Workflow:

 User stories: 

  • The requirements of the product are splitting into smaller specifications or stories. 
  • Each story should have a description that should help any team member to understand exactly what needs to be done. 
  • Stories are estimated in points (which is a measure of effort) or time.


Backlog: The backlog is a group of user stories that contain every task that needs to be performed. Once a story is assigned to a sprint, it is no longer in the backlog.

Sprint: The project is divided in time periods of 2 weeks (this number can be changed but 2 is the default duration).

  •  Each sprint is planned in advance on a meeting called Sprint planning that aims to select the stories that will be worked during that sprint and also who is going to work on each story. 
  • Usually each sprint will focus on a specific area of the project whenever is possible or needed.

 Sprint planning: 

      • Performed on the first day of the sprint, as soon as possible
      • The team mutually discusses and agrees on the scope of work that is intended to be done during that sprint.
      • The client with the product owner decides which  items of the backlog could be completed in one sprint.
      • The team also has a chance of re-estimating time consumption for each task and discussing any possible risks or issues that may delay the completion of that task.
      • Recommended duration is up to 4 hours divided in two parts:
        1. During the first half the whole scrum team selects the product backlog items they believe could be completed in that sprint.
        2. During the second half, the development team identifies the detailed work (tasks or stories) required to complete those product backlog items; resulting in a confirmed sprint backlog.
        3. It’s imperative to verify all needed information is written down in the user story, including UX/UI designs or any links pointing to them.

 Daily Scrum meeting:

      • A short call or meeting every day, that should last no longer than 15 minutes, some teams do it stand up, to avoid the comfort and end it quickly and effectively.
      • Each member explains briefly which tasks he/she worked on the previous day, which tasks are going to be worked today and any possible impediments.
      • Any team member is welcomed in the scrum but only the development team should contribute.
      • The meeting is performed every day at the exact same time even if any team member is missing.
      • Any impediment (block, risk, issue, delays, assumptions proved unfounded) identified on the daily meeting should be captured and addressed by the Scrum master

 Sprint review:

      • Performed at the end of every sprint.
      • The team reviews work that was completed and the planned work that was not able to be completed.
      • The team presents completed work to the stakeholders (known as “demo”)
      • Discuss and collaborate with stakeholders on what to work on the next sprint.
      • Recommended duration is 2 hours.

 Sprint retrospective: The team reflects on the past sprint.

      • Identifies and agrees on continuous process improvement actions.
      • Each identified issue is called an Action Item, and it could be assigned to a person who will be in charge of seeing it improved or resolved.
      • Four main topics should be discussed:
        1. What went well during this sprint?
        2. What did not go well?
        3. What could be improved for better productivity in the next sprint?
        4. Follow up of previous action items (this should be done at the beginning if action items exist)
      • Recommended duration is one to one and a half hours.
      • This event is facilitated by the Scrum master

 Backlog refinement:

    • This is not an obligatory meeting and should only be performed when needed.
    • The goal is to review the backlog items and check if they are appropriately prepared and ordered in a way that makes them clear and executable for team once they enter sprints via the sprint planning activity. Therefore this meeting needs to be performed before the sprint planning, usually at the end of the current sprint.
    • Technical debts can also be introduced to the backlog in this meeting. These are tasks related to re-working or refactoring old code that needs to be improved for different reasons.


“Talent wins games, teamwork and intelligence win championships”
Michael Jordan

Technical team definitions:

 UX/UI Team:

  • The role for this team is to gather and evaluate user requirements, in collaboration with product managers and engineers.
  • Illustrating design ideas using storyboards, process flows and sitemaps.
  • Designing graphic user interface elements, like menus, tabs and widgets
  • Build page navigation buttons and search fields
  • Develop UI mockups and prototypes that clearly illustrate how sites function and look like
  • Create original graphic designs (e.g. images, sketches and tables)
  • Prepare and present rough drafts to internal teams and key stakeholders
  • Identify and troubleshoot UX problems (e.g. responsiveness, accessibility)
  • Conduct layout adjustments based on user feedback.
  • Adhere to style standards on fonts, colors and images.

 Front-end Team:

  • The role for this team is to develop new user-facing features,
  • Build reusable code and libraries for future use,
  • Ensure the technical feasibility of UX/UI designs,
  • Optimize application for maximum speed and scalability,
  • Assure that all user input is validated before submitting to back-end,
  • Collaborate with other team members and stakeholders.

 Back-end Team:

  • Back-end Developers create, code, and improve the server, server-side applications, and databases that, when combined with front-end code, help create a functional, seamless experience for the end-user. They study industry trends, create or improve back-end processes and codes, and work with others to design a better program.
  • Compile and analyze data, processes, and codes to troubleshoot problems and identify areas for improvement.
  • Collaborating with the front-end developers and other team members to establish objectives and design more functional, cohesive codes to enhance the user experience.
  • Developing ideas for new programs, products, or features by monitoring industry developments and trends.
  • Recording data and reporting it to proper parties, such as clients or leadership.

 QA Team: 

  • The role for this team is to review and analyze system specifications,
  • Collaborate with QA Engineers to develop effective strategies and test plans,
  • Execute test cases (manual or automated) and analyze results,
  • Evaluate product code according to specifications,
  • Create logs to document testing phases and defects,
  • Report bugs and errors to development teams,
  • Help troubleshoot issues,
  • Conduct post-release/ post-implementation testing,
  • Work with cross-functional teams to ensure quality throughout the software development lifecycle.


Devops Team:

  • DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality.
  • Infrastructure as Code (IaC) — server environments are described in declarative manifests, that are stored as code, can be adjusted by any team member and reused multiple times to provision the required infrastructure for testing or building the code, as well as for maintaining the app in production.
  • Continuous Integration (CI) — the feedback from project stakeholders and end users are constantly integrated into the product in the form of specs and feature requests for the next iteration of software development.
  • Continuous Delivery (CD) — automatic code delivery pipelines are in place to ensure all the required resources are provisioned automatically and the code is pushed into production as soon as it passes the tests, without additional manual actions of the DevOps engineers or without interrupting the end user experience.
  • Achieving the “no service downtime” is available due to using rolling updates and other DevOps practices.



We hope you have benefited from the content of this note. We invite you to share it and comment what do you think about it. What process do you use for your projects? Did you know Scrumban?

We also invite you to check the projects we have being doing, in our work.