The Agile methodology is intended to simplify complex projects – IT operations or software development use the methodology for a High-Velocity Product Development. Agile set of policies and values that organizations attempt to follow every day, and it is flexible to fit the requirements of the project. In software, teams often use a framework like Scrum or Kanban. Let us dive deep into Scrum based project management, we’ll be discussing the major units of the process.
The product backlog is an artifact of Scrum. This is the complete list of the functionality that remains to be added to the product. The product owner prioritizes the backlog so the team always works on the most valuable features first.
The Agile product backlog in scrum is a prioritized features list, containing short descriptions of all functionality desired in the product. When applying Scrum, it’s not necessary to start a project with a lengthy, upfront effort to document all requirements. Typically, a Scrum team and its product owner begin by writing down everything they can think of for agile backlog prioritization. This agile product backlog is almost always more than enough for a first sprint.
A typical Scrum backlog comprises the following different types of items:
- Technical work
- Knowledge acquisition
Part of the product owner responsibilities is to have a vision of what he or she wishes to build, and convey that vision to the scrum team. This is the key to successfully start any agile software development project. The agile product owner does this in part through the product backlog, which is a prioritized features list for the product.
The ScrumMaster is responsible for making sure a Scrum team lives by the values and practices of Scrum. The ScrumMaster is often considered a coach for the team, helping the team do the best it possibly can. The ScrumMaster can also be thought of as a process owner for the team, creating a balance with the project’s key stakeholders, who is referred to as the product owner.
While the ScrumMaster focuses on helping the team be the best that it can be, the product owner works to direct the team to the right goal. The product owner does this by creating a compelling vision of the product, and then conveying that vision to the team through the product backlog.
The Scrum model suggests that projects progress via a series of sprints. In keeping with an agile methodology, sprints are time boxed to no more than a month long, most commonly two weeks.
Scrum methodology advocates for a planning meeting at the start of the sprint, where team members figure out how many items they can commit to and then create a sprint backlog – a list of tasks to perform during the sprint.
During an agile Scrum sprint, the Scrum team takes a small set of features from idea to coded and tested functionality. At the end, these features are done, meaning coded, tested and integrated into the evolving product or system.
Sprint Planning Meeting
In Scrum, the sprint planning meeting is attended by the Product owner, ScrumMaster and the entire Scrum team.
During the sprint planning meeting, the product owner describes the highest priority features to the team. The team asks enough questions that they can turn a high-level user story of the product backlog into the more detailed tasks of the sprint backlog.
There are two defined artifacts that result from a sprint planning meeting:
1. A sprint goal
2. A sprint backlog
What is a Sprint Backlog?
The sprint backlog is the list of tasks the team needs to perform in order to deliver the functionality that is committed to deliver during the sprint.
During the sprint planning meeting, the team selects some number of product backlog items, usually in the form of user stories, and identifies the tasks necessary to complete each user story.
Release Burndown Chart
Progress on a scrum project can be tracked by means of a release burndown chart. The ScrumMaster should update the release burndown chart at the end of each sprint.
Burndown charts show the amount of work remaining either in a sprint or a release, and are an effective tool in Scrum software development to determine whether a sprint or release is on schedule to have all planned work finished by the desired date.
The horizontal axis of the sprint burndown chart shows the sprints; the vertical axis shows the amount of work remaining at the start of each sprint. Work remaining can be shown in whatever unit the team prefers — story points, ideal days, team days and so on.
In Scrum, each sprint is required to deliver a potentially shippable product increment. This means that at the end of each sprint, the team has produced a coded, tested and usable piece of software.
During the sprint review, the project is assessed against the sprint goal determined during the sprint planning meeting. Ideally, the team has completed each product backlog item brought into the sprint, but it’s more important that they achieve the overall goal of the sprint.
Participants in the sprint review typically include:
1. Product owner
2. The Scrum team
3. The ScrumMaster
4. Customers (optional)
The Sprint retrospective meeting is an opportunity to reflect on the sprint that has ended, and identify opportunities to improve.
This is usually the last thing done in a sprint. The entire team, including both the ScrumMaster and the product owner should participate. A scrum retrospective will be scheduled for up to an hour, which is usually quite sufficient. However, occasionally a vital topic will arise or a team conflict will escalate and the retrospective could take significantly longer.
Sprint retrospective is usually conducted as a start-stop-continue meeting. This is perhaps the simplest, but often the most effective way to conduct a retrospective. Using this approach each team member is asked to identify specific things that the team should:
- Start doing
- Stop doing
- Continue doing
At the end of the sprint, the next retrospective is often begun by reviewing the list of things selected for attention in the prior sprint retrospective. The complete process of Product Development would be iterations of the steps mentioned above.
Next comes the Quality Assurance process in Product Development
Perfomatix has a dedicated independent testing team referred as QA Team with rich skills and experience in product testing. Test Manager identifies and allocate project reviews as per the requirements [draft Blueprint document] for understanding testing scope, limitations or feasibility issues if any and accordingly inform the customer where required.
Parallel to development activity Test Lead prepares a detailed device matrix and test strategy document detailing the testing scope and approach for system integration testing of the application. Project Manager, Test Manager and Delivery director reviews the test strategy document to ensure all activities for effective testing of the application are identified and planned for. Where agreed contractually, the test strategy document is sent to the customer for sign-off before initiating the testing.
Testing team documents test cases for validating all test scenarios, client side functionality and data integration and for all devices in scope. Test data is generated or obtained from customers based on the availability. Test cases are reviewed and base-lined before initiating the testing activity.
Based on the testing scope, functional testing, error handling, regression and user interface testing are conducted on devices in scope. As part of non-functional testing installation and configuration verification, security and performance testing are conducted depending on the testing scope.
During testing all defects are logged under “Defect Management workflow” in Enterprise Project Management tool(Zoho/JIRA) and are tracked to closure. Once all defects are resolved, the code is base-lined and is released for User Acceptance Testing with detailed Release Notes.
All the environments – development, QA, UAT are created by an independent hosting team depending on the project requirement; Configuration and Change Management practices are strictly followed in order to ensure integrity of code during development, testing and release.
Did you like this blog?
Talk to our experts now and let us be your innovation partner!