Author: damien richeux

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.


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


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:



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.


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.

Damien Richeux

Damien Richeux

Damien Richeux

I specialised in the development of capabilities for companies to stay competitive, profitable and sustainable over the long term.

While technology has changed common business practices forever, technology has enabled companies to the vast potential of the new exiting opportunity, which in most cases leaves IT departments scratching their heads as to how to keep up with the continuously involving Market.

In a nutshell, If you want to be or stay ahead of your competitors, you’ll want to deploy powerful ICT and software solutions that can facilitate your business growth and seamlessly integrate across all levels.

Being a part of the Magnificent 11 team allows me to deliver strong suite of capabilities starting with a skilled and experienced Business Analyst team, a track record for solving our customers problems and delivering solid solutions,  far-reaching analysis capable to exceed our customers expectation.

I am passionate about most things, I released recently that I love to create and express myself through drawing, designing and problem solving approach in everything I do. I actually started learning how to build small gaming apps for smartphones, it’s fun, I learn a lot about coding and programing and you can vitally create anything you want.

I am also passionate about self-development, for example I was ask recently the following question: Hardly any person ever sets out to become an average or below average performer, yet over 80% of entire workforce is working at average or below average levels. What gives?

There is many reasons as to why over 80% of the entire workforce is working at average or below average levels. However, even if these reasons are true for me, they may not be true for someone else.

There is a golden rule in the business world that says 80 percent of your business is performed by 20 percent of your customer base. This means that just 20 percent of your clientele accounts for the largest percentage of your profit from year­ to­ year and that you should do everything in your power to please this 20 percent and keep each as a customer.

The same golden rule applies here, the top 20 percent of performer’s account for the largest percent of the entire workforce, then the middle 70 percent, and the bottom 10 percent.
I have a set of 3 questions for the 80% of the entire workforce:

● Why are you not in the top 20% yet?
● When would you be in the top 20%?
● How will you get to the top 20%?

I believe that the lack of passion, clarity, goal setting or choosing the wrong career path can dramatically impact the overall performance and results of the individual in his or her chosen field.
Which ultimately will slower his or her progress to the top 20%, moreover if there is no conviction or commitment. A decision needs to be made and only you can make it for yourself. For me the main reason for average of below average levels is that most people hate their job, which provides them a license for non­performance. Believe it or not, by declaring that you hate your job, you find a sense of relief that you don’t have to perform that much because “how can you be a superstar in a job that you hate?

Another phenomenon happens when people hate their jobs. The focus is “off” of you once you hate your job. If you find one or more reasons (your boss, your pay, working conditions etc.) to hate your job, you can be assured that the focus is “off” of you for an indefinite period as you are now simply looking at how “something else” needs to be fixed for you to love your job. In the process, you can forget your priorities and be guilt­free.

Lastly, I want to say that there is a “small percentage” of “reasons” and “circumstances” that provides genuine reasons to hate your job. But the percentage is very very small. In general, the fix is in “you” and not in the job.

I am greatly inspired spiritually by Jesus Christ who is in my opinion the greatest messenger and leader of all times. The Christian faith represents approximately one ­third of the world’s population and is the largest religion in the world. According to the Pew Research Center the Christianity represented a total of 2.2 billion of adherents across the world. This means that Jesus’s message of peace brings comfort to one­ third of the world’s population including me. Quote message of peace:

Matthew 11:15 He that hath ears to hear, let him hear. Luke 4:18 The Spirit of the Lord is upon me, because he hath anointed me to preach the gospel to the poor; he hath sent me to heal the brokenhearted, to preach deliverance to the captives, and recovering of sight to the blind, to set at liberty them that are bruised.

There are many leaders I admire who have influenced my own leadership. I admire the teachings on leadership by guys like John Maxwell,Steve Jobs, and Arnold Schwarzenegger.

There are leaders from my personal life such as a former pastor, a former boss and leaders in my own community who have influenced me as I have watched their leadership. I love leadership. It is so needed these days; especially in today’s world.

The principles, however, that I admire most are found in the leadership style of Jesus. Jesus’ leadership is still impacting culture today.

Jesus was willing to invest in people others would have dismissed.​Consider thedisciples. They were not the “religious” elite, yet Jesus used them to start His church.

Jesus released responsibility and ownership in a ministry.​Consider how Jesus sent the disciples out on their own. No micro­management it appears.

Jesus had a leadership succession plan. ​Jesus consistently reminded the disciples that He wouldn’t always be with them. Of course, He was still the “leader”, but He left others to take the ministry forward.

Jesus practiced servant leadership better than anyone.​The King of kings was willing to wash the feet of His followers.

Jesus was laser focused on His vision.​Regardless of the persecutions or distractions, Jesus kept on the mission God had called Him to complete.

Jesus handled distractions with grace.​When the woman who had been bleeding for 12 years touched His garment, Jesus stopped to heal her, even though headed to a definite purpose.

Jesus was into self­-development.​Jesus constantly slipped away to spend time with God.

Jesus was into leadership development and replacement.​He very purposefully prepared the disciples to take over the ministry. He pushed people beyond what they felt they were capable of doing.

Jesus held followers to high expectations.​Jesus was not afraid to make huge requests of people. “Follow Me” meant the disciples had to drop their agenda to do so. He told the disciples they must be willing to lose everything to follow Him.

Jesus cared more about people than about rules and regulations.​He was willing to jeopardize Himself personally by breaking the “rules” to help someone in need.

Jesus celebrated success in ministry.​He rewarded people generously who were faithful to Him and His cause.

Jesus finished well.​Any questions whether His ministry was effective? Still working today.


LinkedIn: Damien Richeux



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 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