Partner Article

8 Excellent Practices to Initiate a Scrum Project

Starting a scrum project can be tricky for a person not familiar with the requirements and details. Several aspects like creating the product vision and product backlog together, estimating the backlog, etc. can make a person nervous about how to go about the task. The purpose of Scrum is to create done, usable and potentially releasable increments. That increments which deliver value to customers each iteration and eventually fully satisfy the customer.

A value-driven company also embraces value-driven contracts. These contracts that have a foundation built on transparency and trust. In reality though, value-driven contract is difficult. A great idea from the customer has endless possibilities. The scrum master has to agree upon the contract. A mutual trust between the customer and supplier usually is required but it is often not the case therefore right from the foundation, the trust is missing.

The key question in this scenario is how to start a scrum project and setup a contract that focuses on outcome instead of output? Now I’ll share some scrum best practices where a customer is an external client asking support for a software development project.

1. Create the Product Vision and Backlog Simultaneously

It is often the case as the customer has an idea about the product and it’s possibilities but a product backlog is still missing. A better practice is to arrange a workshop with the customer and the supplier’s development team and letting them create the product backlog together. By doing this, the customer and supplier really get to know each other well helping them out in the future correspondence. Above all, the customer meets the actual development team who can realize his dream.

2. Estimating the Implementation Effort of the Product Backlog Together

Once product backlog is created together, it’s also possible to estimate it in the presence of the customer. The advantage is the customer hears all the discussions and questions and can reply on the spot. A possibility is that complexity may be developed which can be detected and discussed together which ensures mutual understanding about the given estimations.

3. Determine the Business Value of the Product Backlog Together

When the product backlog is estimated in implementation effort, the next step is determining the business value. This is up to the stakeholders. Concurrently, facilitate the stakeholders to discuss and determine the business value for every product backlog item using business value points. The goal is a shared understanding of the priorities and inviting the stakeholders to participate in defining what is more valuable.

This practice forces them to prioritize the product backlog without delegating this responsibility entirely to the product owner. After estimating the implementation effort completed entirely by the development team and determining the business value done by stakeholders a matrix appears. It offer great insights into low business effort, business value, etc.

4. Clarifying the Dependencies between Product Backlog Items

When the implementation effort and business value is determined for every product backlog item, the next logical step is to detect the dependencies. Technical ones can be clarified by the development team while functional dependencies might also be detected by the product owner and stakeholders. Insights like where bottleneck is present and how to solve the dependencies is the main question of concern here.

5. Initiate Modestly

Only one sprint should be agreed upon even if a customer has a huge budget for his project. One you have created and estimated the product vision and product backlog together, only conduct the first Sprint with the goal of delivering the first done, valuable and potentially releasable increment. Perform a sprint review and sprint retrospective and decide if there’s enough mutual trust to start another sprint.

6. The Scrum Events and Invitation to the Customer

It is imperative to invite the customer to all the scrum events. It is done to let the customer experience how the daily scrum is done and the discussions during the sprint planning and share all the lessons learned during the Sprint Review. The feedback especially is very important concerning the delivered product and evaluate the collaboration.

7. Sell the Complete Scrum Team

It’s a golden opportunity for a fixed scrum team which has been working together for a long time and knows the up’s and down’s in sprints. A common hiccup here is to separate this winning team when a new project is on the line. So avoid it all costs. Keep the team together no matter what scenario arises. The customer gets the entire team including the QA, designer, Scrum Master, etc.

8. Sell Sprints

It’s easier to work with fixed teams which know its capacity to work and that’s why it’s easier to sell sprints for this team. The capacity and time frame in which a team can work can be judged in 3-5 sprints. However, a fixed, experienced team knows that exactly what are their capabilities and what they can achieve in a project. The cost/sprint is another important factor that should be considered and because the tea is fixed they know what the cost/sprint would be.

During every sprint review, the scrum team and stakeholders can discuss the desired features that should be developed during the upcoming Sprint.

As I stated in the beginning of this blog, several aspects like creating the product vision and product backlog together, estimating the backlog, etc. are important part of a scrum project.

Need any additional clarification and want to add something to this blog? Please feel free to use the comments box below.

This was posted in Bdaily's Members' News section by anwer .