Category: SCRUM

Estimating the total cost of Agile projects

Estimating the total cost of Agile projects

Estimating the total cost of Agile projects

Questions about how to estimate the total cost of Agile projects are questions about how to do fixed-price, fixed-scope contracts. Fixed-price, fixed-scope contracts are adversarial and often mutually disadvantageous, so I wouldn’t encourage them.

How would a team estimate the cost of fixed-scope work upfront? Here are several approaches for you to consider:

Estimate the project the same way you currently do. If the approach that you’re using provides enough accuracy and you’re able to make a profit, then why change? Any other approach is as likely to be as inaccurate as what you have now.

Estimate the project using a coarse scale … such as T-shirt sizing, and then assign a dollar range to each size. For example, have the team work with the product owner to create a list of User Stories at a high level (epics). The team then estimates the epics on a very coarse abstract scale such as T-Shirt sizes ranging from XS through to XL [XS, S, M, L, XL]. Because we’re only concerned with order-of-magnitude and not about accuracy, this should be a relatively quick operation.

We would then assign a dollar range to each size on our scale; XS would be $10,000-$20,000, S would be $40,00-$80, 000, M would be $150,000-$200,000, etc. We would tally up the final figure to give an upper and lower bound for the total cost.

If the customer wanted a fixed price project then we would quote the upper bound figure to compensate us for the additional risk that this might incur. If they’re willing to work on a more flexible basis (say fixed-cost, variable-scope), then we could consider a quoting a lower cost.

Change the conversation. Changing the conversation is my preferred solution, because changing the conversation helps to educate the client that Scrum is more than a different way to do the same old thing … rather it’s systemic change.

waterfall-network

This approach is also the most difficult.

To use it effectively requires a mature understanding of the different arguments for and against. It is also a realistic answer to the question of how to determine the cost of software upfront. We don’t know [although we can provide educated guesses.

A more meaningful question is how much does the client value the new software? If the client is unable to answer that question, then perhaps the new software has no value at all and is not worth creating. If the client has an understanding of the value of the software (perhaps through a cost/benefit or ROI analysis) then the breakeven point should serve as then upper bounds of the teams budget.

Taking this approach is not without its risks. There is certainly the possibility that the client will decline our services. Mature agile consultancies understand this and are often willing to walk away from work that results in a mutually disadvantageous arrangement.

Source and additional source:

Costing Agile projects: How to cost Agile projects

Software estimates: the total cost of Agile projects

SCRUM | There are three artifacts

SCRUM | There are three artifacts

There are three artifacts in Scrum,

The Product Backlog, the Sprint Backlog and the Burndown  Chart

The Product Backlog is a list for all the requirements. These are high level user stories that features descriptions, all of which have business value priorities. The product backlog is constantly changing. The Product Owner  owns this backlog, he or she will gather feedback, suggestions and additional requirements from stakeholder to add to the backlog. In other types of project management methodologies, there are heavy requirement documents, technical specs, etc. Fortunately with Scrum, the Product Backlog replaces these and the agility is well used with the ability to easily adjust the content of this.

A typical Scrum backlog comprises the following different types of items:

  1. Features
  2. Bugs
  3. Technical work
  4. Knowledge acquisition

Productbacklog-and-Sprint-Backlog

Conceptually, the team starts at the top of the prioritized Scrum backlog and draws a line after the lowest of the high-priority items they feel they can complete. In practice, it’s not unusual to see a team select, for example, the top five items and then two items from lower on the list that are associated with the initial five.

The Sprint Backlog is a subset of the Product Backlog. This is the repository of the highest priorities deemed by the Product Owner. These requirements are broken out into tasks, estimated, and clearly defined by the Scrum Team. Once we start a Sprint, the Sprint backlog does not change.

The sprint backlog is commonly maintained as a spreadsheet, but it is also possible to use your defect tracking system or any of a number of software products designed specifically for Scrum or agile.

An example of a sprint backlog in a spreadsheet looks like this:

TheSprintBacklog

 

The Burndown Chart is a chart that indicates how much work is remaining in the Sprint. This chart is hung up in an area that everyone can easily see, including the Scrum Team, the Product Owner and Management. This is updated on a daily basis by the ScrumMaster, after hearing from the team what they have accomplished in the Daily Scrum Meeting.

SampleBurndownChart

Let’s take an example using the sprint burndown chart above. As you can see, the team in this scenario pulled in too much work initially into the sprint backlog, and still had nearly 250 hours to go on day 8 of a 21-day sprint. The product owner was consulted and agreed to remove some user stories from the sprint. This resulted in the drop on the chart between days 7 and 8. We can also see that on day 8 they had completed nearly 35 tasks. From there, the team made consistent progress and finished the Scrum sprint successfully.

SCRUM | 3 essential roles

SCRUM | 3 essential roles

There is three essential roles for scrum to work successfully

As discussed in my previous post “Introduction to SCRUM” the scrum team has a different composition than a traditional waterfall project, which include three specific roles: product owner, scrum master, and the development team or also called delivery team.

SCRUM 3 Roles

Scrum teams are cross-functional, “the development team” includes developer, testers, designers, and ops engineers in addition to developers and sometimes the customer.
The product owner

Product owners are the champions for their product. They are focused on understanding business and market requirements, then prioritizing the work to be done by the engineering team accordingly. Effective product owners:

Build and manage the product backlog
Closely partner with the business and the team to ensure everyone understands the work items in the product backlog
Give the team clear guidance on which features to deliver next

However let’s keep in mind that the product owner is not a project manager. Product owners are not managing the status of the program. They focus on ensuring the development team delivers the most value to the business. Also, it’s important that the product owner be an individual. No development team wants mixed guidance from multiple product owners.
The scrum master

Scrum masters are the champion for scrum within their team. They coach the team, the product owner, and the business on the scrum process and look for ways to fine-tune their practice of it. An effective scrum master deeply understands the work being done by the team and can help the team optimize their delivery flow. As the facilitator-in-chief, they schedule the needed resources (both human and logistical) for sprint planning, stand-up, sprint review, and the sprint retrospective.

Scrum masters also look to resolve impediments and distractions for the development team, insulating them from external disruptions whenever possible.

Part of the scrum master’s job is to defend against an anti-pattern common among teams new to scrum: changing the sprint’s scope after it has already begun. Product owners will sometimes ask, “Can’t we get this one more super-important little thing into this sprint?” But keeping scope air tight reinforces good estimation and product planning–not to mention fends off a source of disruption to the development team.

Scrum masters are commonly mistaken for project managers, when in fact, project managers don’t really have a place in the scrum methodology. A scrum team controls its own destiny and self-organizes around their work. Agile teams use pull models where the team pulls a certain amount of work off the backlog and commits to completing it that sprint, which is very effective in maintaining quality and ensuring optimum performance of the team over the long-term. Neither scrum masters nor project managers nor product owners push work to the team (which, by contrast, tends to erode both quality and morale).

The scrum team

Scrum teams are the champions for sustainable development practices. The most effective scrum teams are tight-knit, co-located, and usually 5 to 7 members. Team members have differing skill sets, and cross-train each other so no one person becomes a bottleneck in the delivery of work. Strong scrum teams approach their project with a clear “we” attitude. All members of the team help one another to ensure a successful sprint completion.

As mentioned above, the scrum team drives the plan for each sprint. They forecast how much work they believe they can complete over the iteration using their historical velocity as a guide. Keeping the iteration length fixed gives the development team important feedback on their estimation and delivery process, which in turn makes their forecasts increasingly accurate over time.

Introduction to SCRUM

Introduction to SCRUM

“SCRUM”, is not a French word or the latest Scratch Back App but instead it is one of the smartest tool in our Magnificent11 BA Tool box.

Scrum is an Agile framework for completing complex projects. Scrum originally was formalized for software development projects, but it works well for any complex, innovative scope of work. The possibilities are endless. The Scrum framework is deceptively simple.

Use Scrum to improve teamwork, communications, and speed!

In this series, I will introduce you to the wonderful world of “SCRUM” by covering the basics, comparing it to the Waterfall development approach and show you the key fundamentals that makes “SCRUM” the favorite Agile methodology at Magnificent11.

In today’s post, we’ll focus on comparing the Waterfall development against Scrum Agile development. We need to understand the differences between  Waterfall and Scrum which will highlight the benefits of Agile development.

The WATERFALL developmentWaterfall

Waterfall is usually describe to be a long painful process from the first “Idea” all the way through “Development” or Building the software, this part is usually called “Planning”. Each step takes several months, the main problems is that Planning must take plan before any work can start and in most cases the planning is done without completely understanding or the project.

Most of the time, when there is a problem in the “development” process things have to be send back the “Idea” to go under additional planning. The same type of issue happens in the “Test” and deployment or “Final Product” process, this will ultimately create major delay such as many months or sometimes years before the product is out the door!

Considering the changing market, fast moving competition and new emerging and innovative start-up, you don’t have to be a genius to understand that your original “Idea” recorded 12 to 18 months ago will not stack up with the surrounding of “today’s world”.

SCRUM an Agile Methodology

Scrum

Scrum is an Agile methodology which takes the process of development and breaks it down into smaller pieces call Sprint. Each sprint including the following process:

  1. PLAN: First will do just enough planning to get started.
  2. BUILD: Building the minimal feature set and actually build what was planned.
  3. TEST: Test the small feature set
  4. REVIEW: Review and potentially have shippable product

This process take about 2 to 3 weeks, this is then repeated time and time again  reducing the time to development, to testing each time through the planning process so that we do just enough to complete the incremental releases. You will then end up with several incremental release call SPRINT, a Sprint usually take 1 to 3 weeks and you keep repeating these Sprints until your product is features complete. Sometimes is will take 3 Sprint or 4 Sprint or even more, but you eventually end up with a final product.

One of the key benefits of Scrum are the multiple touch points across each Sprint, there will always be an opportunity to adjust, adapt or make a change before a feature is complete. By the end of a project, containing for example 4 Sprint, you will have 4 opportunity to Plan, Build, Test, Review and the ability to modified a specific item without compromising the project.

Thank you for reading, I hope that it’s been informative and feel free to leave a comments below we would love to hear from you.

Next week we will focus on the 9 Key Component of SCRUM which are indispensable for the Scrum frame work to work well.

  1. 3 Key Roles
  2. 3 Artifacts
  3. 3 Ceremonies