Software Development Process

We are Agile development team but also work with traditional development process like waterfall, SDLC but since most organisation are gearing towards quick market delivery, below is our agile approach.

  • Stakeholder Input
  • Refinement
  • Sprint Planning
  • Sprint Backlog
  • Sprint
  • Daily Scrum
  • End of Sprint

Stakeholder Input

  • Used to drive the work
  • Outlines the business requirements of the customer
  • Often not prioritised
  • Represents large items of work (typically devoid of specific detail) Features/User Story backlog
  • Features & User Stories represent the business requirements that the product owner or business analyst(s) have documented from the stakeholders (written in connextra format)
  • The backlog can also contain Defects/Bugs discovered by the team as a separate type of user story
  • The product owner is responsible for ensuring the backlog is ordered by descending business value & release, known as backlog Grooming

Ideally, only the highest priority user stories will be broken down the closer they are to being worked on in a sprint. Items of work planned for some future sprint will often reflect larger pieces of work in need of review and breaking down, a process known as user story refinement.

Refinement

  • Refinement is the process of breaking down business requirements/user stories into bite size chunks that allow the scrum team to achieve the objective within 1 sprint
  • Time-boxed at no more than 1 hour per week of sprint
  • The ceremony involves the whole scrum team and gives everyone a chance to:
    • review the details of the requirements
    • voice any concerns/questions
    • ask for more information/clarity
    • highlight any dependencies/blockers/barriers
    • estimate the work (in story points)
  • Once a user story reflects the Definition of Ready then it is in a state where it can be included in a sprint

Sprint Planning

  • Ceremony lead by the scrum team
  • The scrum team discusses and commits to accepting as much work that complies with the Definition of Ready that can be fully completed by the end of the sprint
  • The scrum team will review the items accepted in the sprint and break them down into the composite sub-tasks
  • Each task will be assigned to a relevant team member (where applicable)

NOTE: Allocation of tasks may wait until closer to when they are being worked on and based on each team member’s availability

Sprint Backlog

  • The sprint backlog represents the work that the team has committed to fully completing within a sprint and the break down of those items of work into sub-tasks
  • Ideally the end date and deliverable(s) should not be changed even by the Product Owner

Sprint

  • A time-boxed period of 1 – 4 week, where user stories are worked on by the scrum team to completion
  • All work completed should adhere to the team’s Definition of Done

Daily Scrum

  • A daily scrum ceremony where the scrum team meets to discuss their progress and to highlight any issues that they are encountering that may affect their ability to complete their objectives within the sprint
  • Time-boxed to no more than 30 minutes

End of Sprint

  • All committed items of work should be fully completed (including testing, deployment & UAT sign-off) as defined by the Definition of Done
  • The product owner should have the choice to execute a release if desired/needed
  • The scrum team host a review to demonstrate the work that has been completed to the stakeholders (as appropriate)
  • The scrum team holds a retrospective to discuss what went well, what didn’t go so well and what things could be changed to improve the next sprint

Start Your Project with Europe IT Solutions