Scrum - Agile Software Development
Agile Software Development
Agile software development is an approach to software development that emphasizes flexibility, collaboration, and customer satisfaction. It is based on the principles outlined in the Agile Manifesto, which was created by a group of software developers in 2001. Agile methodologies prioritize iterative development, incremental delivery, and the ability to adapt to changing requirements throughout the development process.
In PowerFolder we use a customized version of Scrum, tailored as per our needs and customer requirements.
Key principles and characteristics of agile software development include:
Iterative Development: Agile projects are typically divided into small increments or iterations, with each iteration delivering a potentially shippable product increment. This allows for continuous improvement and the ability to adapt to changing requirements.
Customer Involvement: Agile encourages frequent and close collaboration with customers and stakeholders. This ensures that the delivered product meets customer expectations and can adapt to changing needs.
Collaborative Teams: Cross-functional teams, consisting of members with different skill sets (developers, testers, business analysts, etc.), work collaboratively throughout the project. This fosters better communication and collective ownership of the project's success.
Flexibility and Adaptability: Agile processes are designed to be flexible and able to respond to changes quickly. This is in contrast to more traditional, plan-driven methodologies that may struggle to accommodate changes late in the development process.
Continuous Delivery: Agile emphasizes the importance of delivering functional software at the end of each iteration. This allows for early and frequent releases of product increments, providing tangible value to the customer throughout the development process.
Embracing Change: Agile teams welcome changing requirements, even late in the development process. The ability to adapt to new information and priorities is considered a strength rather than a hindrance.
Feedback Mechanisms: Regular feedback loops, such as daily stand-up meetings and retrospectives, help teams to continuously improve their processes and address any issues that may arise.
Scrum Team
Person | Role |
|---|---|
Christian Sprajc | Product Owner |
Ahmad Abdullah | Scrum Master |
Developers | Development Team |
Scrum Board
A Scrum board is a visual representation used in Scrum, an agile framework for managing and developing software. The board serves as a centralized location for the Scrum team to track and manage the progress of work during a sprint or iteration. It provides transparency into the team's activities and helps team members collaborate more effectively. The Scrum board is often a physical board displayed in the team's workspace, but it can also be a digital board in virtual collaboration tools.
States / Elements in Scrum Board
The board is divided into columns representing different stages of the development process. The common columns on a Scrum board include:
Sprint Backlog - Open
This column includes the user stories or tasks committed to and planned for the current sprint.
These tasks are selected depending on their priority from the product backlog through sprint planning conducted by Product Owner and Scrum Master.
These tasks fulfil the “Definition of Ready”.
In Progress - Development
Tasks that team members are currently working on are moved to this column.
The developer is allowed to work only on one task at a time, if two tasks are related to each other than, these can be developed together at a time.
If there are issues in a task, please put back and take the next one after informing the Scrum Master.
The tasks are only done depending on the priorities, these are listed below:
Resolved
Completed tasks are moved here from the development team.
In Review - Code Review
In this stage, the code review and unit tests are done.
In Testing - Review
In this column, the manual QA or customer QA takes place.
Developers are not allowed to do code review or manual QA on their own developed tasks, except the Product Owner.
Tested - Done
Tasks that have been completed and meet the acceptance criteria are moved to this final column.
Closed
The tasks are finished and can be delivered to the customer as they fulfil the “Definition of Done”.
Software Release
After a successful sprint, a major version release is created by Scrum Master and delivered to the customers by Product Owner.