Why IT Teams Should Adopt the Scrum and Story Points Approach
Why IT Teams Should Adopt the Scrum and Story Points Approach
Implemented correctly, a formal Scrum framework can bring many benefits to an IT team, providing the full benefits of a fleshed-out Agile framework.
Join the DZone community and get the full member experience.Join For Free
You've been hearing a lot about agile software development, get started with the eBook: Agile Product Development from 321 Gang.
This post was originally published here.
Scrum is a lightweight organizational framework that focuses on transforming the way you tackle complex projects. The project management approach is based on the concept of breaking a complex project down into simple tasks as well as encouraging you to adapt your process. It facilitates teamwork and helps you do more work in less time.
Scrum has been primarily applied in software development, but it is equally useful in all other business areas. Scrum also optimizes the observation of product deliverables to ensure value optimization. It is Kaizen-driven (with a focus on continuous process improvement).
The drive behind this article is to counter some of the resistance to adopting more formal frameworks like Scrum. Many teams still see such project management approaches as time-sucks and have implemented them, but not fully committed, and so are not seeing the benefits.
Is Scrum Another Approach to DevOps?
Scrum doesn’t replace DevOps, but it’s a great way of reinforcing the methodology’s best practices. It complements DevOps as an approach that speeds up the delivery of secure operational software while also accurately measuring software success. Both Scrum and DevOps are geared to achieve and improve end-to-end IT organizations. Scrum integrates business, development, operations, and security together to support continuous value.
Today’s product development and delivery process involves advancing the flow of ideas through to value creation. DevOps’ emphasis on automation, sharing, and measurement is enhanced through Scrum sprints and improving the flow of information between all parties. Scrum is about rapid cycles and involves all stakeholders not only software development team, hence why it augments DevOps so well.
Why You Should Use Scrum
- Scrum will facilitate your organizational goals by accelerating your time to market. This capability results from early communication across all functions, which consequently leads to a better understanding of production process and improved feedback. Since work is done in small batches, teams can create and supply product deliverables quickly.
- It will help teams focus on the end-user while designing and developing a product to deliver what customers actually want.
- Scrum will increase production. By systematically inspecting and adapting processes with continuous improvement, teams will eventually need less time to produce more.
- Scrum motivates individuals to take on more active roles by involving them in decision making. It also harnesses an IT teams’ talents, thereby improving their working environments and increasing their job satisfaction—which in turn increases productivity too.
- Overall product quality is improved. By encouraging the inclusion of more testing early on in the development process, defects are identified and tackled quicker. Enabling teams to produce and deliver what is needed by the customer sooner.
What are the Advantages of Using Scrum?
- Scrum supports the product owner in formulating the product success roadmap.
- The approach helps set priorities within complicated systems.
- Scrum supports flexibility in that it embraces valuable changes that would lead to product improvement.
- Scrum serves as a guide to the development team throughout the process.
- It also serves as progress reference as the team can routinely check what has been achieved and what is still to be done.
- The approach allows you to test assumptions; risks are addressed quicker and valuable features can be delivered sooner.
Disadvantages of Scrum
- The approach is subject to failure if the whole team is not cooperative. Buy-in must be achieved at all levels.
- Lack of definite end date in Scrum can lead to project scope creep.
- The Scrum framework can be challenging for large and remote teams.
How You Should Use Scrum
The first step is to understand Scrum in your work context. You need to know the framework and identify people to incorporate in certain roles, then examine and organize your backlog. Here is a guide for launching Scrum in your work setup:
- Assign the various job roles as follows:
- Product owner: Identify who will be responsible for maximizing the value of the product delivered by the team.
- Scrum master: Responsible for promoting and supporting Scrum, so assign this role to a person with excellent soft skills in team/people management.
- The development team is the rest of the Scrum participants composed of professionals who will deliver product value at the end of a sprint. (A Sprint is the time measure during which a product value increment will be created.)
- Identify the product backlog: This lists the project tasks the team needs to accomplish. The Scrum Master should prioritize the duties by importance and what needs to be accomplished per sprint. The backlog can be subject to changes if new priority needs emerge.
- Plan sprints: Identify tasks for each person to complete during the first sprint. Decide on a short time length that is reasonable for work to be accomplished within (two/three weeks sprints are ideal). Involve the team members in this crucial decision making.
- Get to the tasks: Start working on the sprint. Everyone should be busy with her/his identified role and job’s list. Arrange daily sprint meetings to report on progress. The meeting should prompt every individual to review and share updates on work performed, work to be performed, and any hindrance that is constraining the process for them.
- Review the work and process, then plan for improvement: At the end of every sprint, the team presents all completed tasks and reviews both the work accomplished and not accomplished. Scrum masters should also hold a retrospective meeting during which the team analyzes the actual work process. During this meeting, encourage individuals to share suggestions on how to improve the process of operations. The suggested improvements should be enacted in the next sprint.
For further insight into Scrum implementation, read the full official Scrum Guide.
Story Points in the Scrum Context
A story point is an element of measurement determined and adopted by Scrum teams to provide a general estimate of the effort needed to complete a task. It is preferred over the person-hours approach for evaluating how difficult a task will be.
Story points being effort driven are contrary to estimating a person-hours approach which relates work done by the projected amount of time a task will take. People are renowned for over- and underestimating the time a project can take, and the number of person-hours potentially involved does not allow for unexpected constraints. Story points allow teams to better predict the number of functionalities that can be delivered by a certain date, making them a more reliable estimation of measurement.
The story points approach uses the Fibonacci sequence to provide estimates. Fibonacci is a set of numbers starting with one and proceeds based on a rule that each number is an aggregate of the two preceding numbers; 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, etc.
Caylent runs sprints of two weeks and manages all works (backlog and current) on Trello boards—the online version of a visual Kanban board. The team uses the site Planning Poker to make individual estimates of the story points assigned for each task for every team member, the general average is then logged onto Trello card for that sprint.
Measuring in Story Points Over Person-Hours
- The story points approach does not relate the skills and experience of the estimator. When estimating a person-hours approach, a specialist would take a shorter amount of time to complete a task compared to those more inexperienced. The story points approach eliminates this problem. They are a standard measure across the entire team and are agreed upon by all the team members.
- The story point approach is based on velocity. Velocity is the quantity of work a team can achieve in a sprint and is deliberated and agreed upon by everyone involved. If the team velocity is increased, the team can potentially take more work. On the other hand, the number of hours can’t always be physically expanded to increase the amount of work done.
- Story points being a measurement of relative sizes, team members can accurately estimate when they can complete a project based on effort involved, not the level of skill.
In a nutshell, the advantages of story points significantly outweigh estimating by the person-hours approach. Story points help Scrum teams manage sprints effectively and deliver high productivity. Teams may be apprehensive about initiating Scrum framework with concerns of the potential time-suck in their daily processes. Give assurance that though it may take a Sprint or two for the benefits to clearly emerge, the commitment is worth the effort. IT teams should seriously consider adopting Scrum to help them effectively and efficiently accomplish organizational goals within DevOps.
Want to read more? Check out our article on Transformational Leadership
Caylent offers DevOps-as-a-Service to high growth companies looking for help with microservices, containers, cloud infrastructure, and CI/CD deployments. Our managed and consulting services are a more cost-effective option than hiring in-house and we scale as your team and company grow. Check out some of the use cases and learn how we work with clients by visiting our DevOps-as-a-Service offering.
Published at DZone with permission of Stefan Thorpe , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.