Effectively Using Product Roadmaps for Agile

By Betsy Kauffman, Organizational Coach, Agile Pi

What is an Agile Product Roadmap?

A product roadmap is essentially an action plan for how a product will evolve to completion. Product roadmaps can be incredibly useful to outline your product functionality and showcase a timeline for when new features will be implemented.

Multiple agile teams can utilize a shared product roadmap. When employed in agile development, a roadmap equips your product with the essential framework for a team’s daily tasks and should be reactive to developments in the competing landscape.

Many agile professionals have turned to product roadmaps as a plan of action to resolve managements need for documentation, but is your roadmap a valuable project tool or just a required artifact created and then cast aside? If you create it and never look at it again, then you’re probably struggling with lots of issues like missed deadlines, frustrated stakeholders, bad/slow decisions and mediocre solutions.

How does a Product Roadmap Improve Projects?

When done well, the Agile product roadmap is the foundation and facilitator of solution delivery. The process to create and periodically update the roadmap generates meaningful conversations that create confident teams who are able to meet their commitments. A good roadmap process helps teams manage expectations, facilitate decision making, and most importantly, estimate and deliver valuable solutions.

A useful and predictable roadmap requires a consistent focus on three things:

  • Transparency
  • Data-Driven Forecasting and Decision Making
  • Reflection

Agile teams who focus on transparency and engage stakeholders in meaningful discussions need to build a sturdy framework for the Agile product roadmap.

The framework should include:

  • Business Capabilities
  • Technical Dependencies
  • Other Project Impacts
  • Market Events
  • Risks/schedule constraints

When teams establish this solid framework across a timeline and commit to frequent recasting, the product roadmap becomes an essential communication and trust-building tool. Leaders and stakeholders understand the product/project plan, and the team becomes confident in their ability to deliver!

About the Author
Betsy Kauffman (CSM, CSPO, PSM, PMP, PMI-ACP, SPC4, ICP-APM, ICP-ACC, ICP-ATF) is a passionate Organizational Coach and Trainer with more than 18 years’ experience working with high performing teams. She has held various roles working as a Business Analyst, Project Manager, Program Manager, Scrum Master, Senior Scrum Master, and Agile Coach across several sectors including healthcare, retail, entertainment and financial. As an Organizational Coach, she is responsible for coaching, training, and implementing best practices at the executive, program and team levels for several Fortune 500 organizations.

Betsy was also selected by Agile Alliance to be one of seven authors for the Agile Practice Guide published in conjunction with the Project Management Institute (PMI)® in September 2017. Betsy is actively involved in the community and enjoys presenting on a range of topics regarding agile transformations, agile management, and agile values.

PMI is a registered mark of the Project Management Institute, Inc.


Why Your Agile Implementation Failed

Join IIL’s virtual conference on Thursday, May 4th for more insights on Agile, Scrum, and Kanban.

By Roy Schilling

At one point in my career, I was a manager in a large financial organization.  Being tired of missed deadlines and disappointed customers, I wanted a better way to deliver – faster, better, cheaper.  I had been reading about Agile and how it had helped organizations with exactly what I was looking to solve.

My Agile journey started pretty much like everyone else – hours on the internet and a 2-day class.  At the end of the class, I was the proud owner of a certificate and had a high-level of confidence that I could implement this Agile thing in my organization.  I quickly looked for a project, formed my team and started executing – now we’re Agile!  The result, however, was something quite different from what I expected.  The team never really formed, we had personalities that didn’t work well together, people were getting yanked out of the team for “special assignments”, and a whole host of other anti-patterns which caused us to ultimately fail – and in a big way.

The reality was that I had no idea what I was doing.  I had no experience and no one to help set up the guardrails needed to keep the team (and me) headed in the right direction.  Sadly, this is a very common situation.  Lots of energy, desire, motivation, but no experience to make it work.  Training was a great start, but not enough to guarantee success.

 

I could have walked away with my failure, and declared Agile to be the problem.  “It just can’t work in my organization” is something I’ve heard far too often as an excuse for simple mistakes.  Instead, I was fortunate enough to have met someone with significant experience in the industry, who offered his help to mentor and coach me.  After spending a short time together, we got my team re-aligned, analyzed skill sets and personalities, setup team working agreements and started working with leadership to help them understand their part in all this.  In short, he got me back on track.

 

One of the most important things he helped me with was in becoming a better leader.  He helped me understand that I was spending too much time managing down, worrying about “resource allocation” and dealing with the minutia of daily activities.  I had hired good people; it was time to get out of their way, let them do their jobs and give them the support they needed to accomplish the goals they set out to achieve.  This was a major change from my management style, and one of the most difficult and important lessons I had ever learned as a manager.  Without his help, I may never have made that leap.

 

To summarize, hiring a coach taught me:

  1. To be an active listener
  2. To give my team the environment and support they need and trust them to get the job done
  3. To effectively communicate with everyone, and always find the time for face-to-face discussions (and daily stand-ups)

 

But most importantly,

He taught me how to successfully implement Agile and get everyone on the same page; how to destroy the barriers and bring a new mentality to the company as a whole.

Having a coach to help me through the transformation (personal and organizational) was critical to the success of my organization.  Without his involvement, I would likely have had failure after failure, or just walked away from it altogether.  The cost to my organization would have been significant due to those failures, and I still would have had disappointed customers.

I’ve since moved on and have become an Agile coach myself, but even with many years’ experience behind me, I still reach out to other coaches and my mentor for advice, and to share my experiences to help others as well.

If you are transforming your organization, or just yourself, take advice from someone who has already gone through it.

Avoid my mistakes – find a coach/mentor, learn from others who have more experience than you, ask for help and embrace your mistakes.


Roy Schilling is an Agile Trainer and Coach and is based in the Charlotte area.  Roy has 30+ years in IT and 16+ years practicing Lean/Agile in small to large organizations. Roy’s certifications include CSM, CSPO, CSP, ACP and ICP-ACC.


I’m a Project Management Professional (PMP)®! Why Do I Need Agile?

By Kellie Morrell   |   Agilist, PMI-ACP & PMP, CSM, CSP, AHF, AFC, ICAgile ICP and ATF
Enterprise Agile Coach and Trainer, Agile Transformation Inc.

That was my question 9 years ago.  I had earned my PMP® certification in 2002 and was proud of it.  I had been somewhat successful in managing my projects; or least the ones where the clients did not change their requirements every other day.  So why would I need to learn something new?

My reason was very simple…my Senior Management asked me to pilot Agile for the organization. My first step was to find out what ‘Agile’ meant since I didn’t have a clue.

Agile Education

I attended a “Real World Agile” course by Agile Transformation, Inc. They also provided me with an Agile Coach. I learned that Agile was just another ‘tool’ in the project management ‘tool box.’  My Trainer and Coach helped me learn the basics of Agile.

[trx_infobox style=”regular” closeable=”no” icon=”icon-ok”]Learn more about IIL’s Agile Project Management courses >>[/trx_infobox]

agile-frameworks

The Main Agile Roles

  1. Product Owner – Business Owner that sets the business vision and priorities of the work. They also accept and/or reject the work the Team does.
  2. Team Members – Developers, Analysts, Testers, Subject Matter Experts (SMEs), etc.
  3. ScrumMaster – Agile Project Manager who facilitates the Agile process and meetings. They also are focused on the Team’s health and removing any impediments or road blocks the Team may have.  This was my new role.

The Main Artifacts

  1. Product Backlog – Requirements log in highest priority.
  2. Sprint or Iteration – A time box of 2-4 weeks where the team designs, codes, and tests and the Team could potentially move to production.
  3. Sprint Backlog – Requirements log of work to be completed in the 2-4 week Sprint.
  4. Burndown Chart – Daily progress of the team burning down their hours to the end of the sprint. Show roadblocks early.

The Main Meetings/Ceremonies

  1. Sprint Planning – What work the team wants to commit to getting done in the next sprint (2-4 weeks).
  2. Daily Scrum or Stand Up Meetings – A 15 minute meeting where you stand up and answer 3 questions.
    • What work did you get done yesterday?
    • What work are you going to commit to get done today?
    • Do you have any impediments?
  3. Sprint Review/Demo – The Team shows the work they have completed to Stakeholders and get their feedback. Time to celebrate as well.
  4. Sprint Retrospective – We called these ‘Lessons Learned’ meetings in Traditional project management and took place at the end of the project. These are completed each sprint and answer these 2 questions.
    • What did we do well this sprint?
    • What could we improve upon for next sprint?
  5. Agile embraces continuous improvement. The team would select 1-2 items from the Retro list that they want to get better at next sprint.

How I Made the Transition from PMP to Agile

Agile is not all that different than Traditional project management. The big change is the focus on People and Value Delivered versus the project management process. In Traditional project management, I always had an Initiation Phase and a Planning Phase. So does Agile. At the end of my Traditional projects, I always had a Release into Production. So does Agile. The big difference is the iterative planning and the iterative development. Agile project teams have a Closing Phase for the project work, but continue on the next highest priority project. Their closing phase is really a few stories and, of course, a celebration.

The big difference in Traditional and Agile is the iterative planning and development. This took me about 3 months to really learn how to break down the large work efforts (epics) into smaller chucks so we could deliver during our 2 week sprints.  I finally learned that the smaller the chunk of work, the better we can understand it, design it, code it, test it, and deliver something valuable that we could get quick feedback on.

agile-lifecycle

Hardest Lessons Learned

  1. I was surprised to learn that Agile aligns with A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Fifth Edition (2013)
  2. I was also surprised on how many other PMPs were doing Agile.
  3. I learned the pros of Traditional Project Management:
    • Structured management
    • Budget and schedule predictability
    • Easy to scale
    • Skills Specialization
    • Documentation = knowledge transferability
    • Familiarity – often part of organizational culture
    • Structural support from other departments
  4. I also learned the pros of Agile:
    • Early and continuous delivery
    • More flexibility
    • More certain to deliver what the customer wants
    • Less defects in the final product
    • Higher visibility with frequent validation and transparent reporting
    • Increased estimating accuracy
    • More customer interaction
    • Improved team morale

traditional-vs-agilepm

Advice for Us “PMPers” Making the Transition to Agile

  1. “You can use all Agile some of the time and some Agile all of the time.” So try it.
  2. Allow yourself time to adjust to the new terminology, roles, process, and iterative development. It took me about 3 months before I began to feel comfortable with the framework and ceremonies.

Summary

Just like a good carpenter, you must know what tool will work the best depending on the job you need to do. Sometimes you will need a hammer; other times it will be an electric drill. The key is to know how both work, so you can select the best project management practices for your Project/Program and your Culture. In the end, what is really important is your organization’s Enterprise Business Agility. The method or framework you select will depend on the project.

Whether a PMP or Agile Certified Practitioner (PMI-ACP)®, our job is to facilitate the projects/programs, drive innovation in our organization, and keep up with the market and competition. Having both Agile and Traditional project management knowledge and experience will make you a better project manager. And you will have a few extra “tools in your PM tool box.”

More insights await at the virtual Agile and Scrum conference, going live on May 4th. 5 keynotes and 20 sessions to choose from, plus networking and PDUs/SEU®s.

 


PMP, PMBOK and PMI-ACP are marks of the Project Management Institute, Inc.


Software Costs Estimation In Agile Project Management

One of the hardest things to do in software development is to determine how long and how much it will take to deliver a new software product. Should it be so hard? The answer is not straightforward.

Software costs estimation is inherently difficult, and humans are terribly bad at predicting absolute outcomes. No two projects are the same;each is unique in what it sets out to achieve, and unique in the myriad of parameters that form its existence. Often, what appears to be a simple problem on the surface is much harder or technically challenging to implement in reality. And, undoubtedly, there will be ‘unknowns’ with the project that can only be identified when they arise.

Additionally, no two people are the same, whether you’re a customer, a developer or a user. We come preloaded with our own set of knowledge, experiences, values, expectations, attitude to risk, and ability to adapt.

Writing good quality software is bread and butter for senior engineers; creating awesome software products can be a much harder endeavour, for all involved.

Delivering Awesome Software is a Balancing Act

But when it comes to software, understanding duration and cost are key in making strategic business decisions and this is true whether you’re creating a startup, realising a new business opportunity, or enabling your business to perform better. The timing, return on investment and benefit delivered can make, shake or break your business. You’ll be asking yourself: What do we get for our money? Can we predict our costs? What will it cost to create the product we want ? When can we launch? Will we get a quality product for our investment? Will it grow with our business? Will it deliver business value?

So, how do you go about estimating the size, duration and cost of a project? Let’s explore Agile project estimation and software development costs, and how we do it at Toptal.

Traditional Contract Pricing and Estimation

Traditionally, using non-Agile practices, software projects have sought to fix functionality or scope, and to let time and cost be a variable. This causes problems:

  1. How do you know that the functionality you fix at the outset of a project really is the functionality that serves your business or customers best? More often than not, functionality or scope will change, which is why we hear about ‘scope creep,’ the outcome of desired needs being identified through the lifecycle of a project and being determined as necessary or compulsory
  2. When cost becomes a variable we lose control over the return on investment (ROI) that we’re seeking to achieve. Increased cost is often a product of unidentified risks or changing requirements, which means we have to add team members to do more work in the same time frame, or keep team members longer. Neither is desirable
  3. When time is a variable, we lose control over the position in our market. Perhaps we miss an important industry date or our competitors get their product out before us, thus losing any competitive advantage our project may have had.

There are many other outcomes of variable time and cost, which are often negative and undesirable.

Of course, many customers and organisations seek to fix all three components of this ‘magic triangle’. Unfortunately, it’s nigh on impossible to realistically achieve. There are too many elements that conspire to unsettle this ideal, which ultimately end in products that don’t meet a need, take too long to benefit its customers or cost too much to realize business value.

Agile Software Costs Estimation Win Every Time

Agile Contracts for Software Projects

Cost is a product of time and people (team members). Add more time, and you add cost for employing people for longer. Add more team members, and you increase cost to deliver the same business value. The things we really want to avoid. This is why Agile principles believe in fixing time and team members and allowing scope to be the variable component.

Which sounds better and increases stakeholder confidence, fixed cost or variable cost?

Of course, it’s important that a product delivers on its promises and the needs of its customers. It’s no good spending an exact amount of time and an exact amount of money, if at the end, you have a product that nobody wants or can use effectively.

So Agile contracts focus on the following:

  • Fixed price work packages – The whole project is broken down into logical ‘mini’ releases which contribute to the full product outcome. Each release is a work package that is priced accordingly. As a work package is completed, future work packages are re-estimated based on what we have learnt from the previous one. This avoids unnecessary contingency and allows for a level of re-prioritisation and new/revised features to be defined by the customer.
  • Early termination – This allows the customer to seek to terminate the project early if enough of the product has been delivered and there is no further ROI to be achieved by retaining a project team that will only continue to deliver marginal gains. This clause is typically allowed at any time and is valid as long as the project team and customer have maintained a strong, trusting and close working collaborative relationship. The benefit for the customer is that the project will finish early, having delivered all the valuable features necessary to make the product viable. In return, the supplier is paid 20 percent of the remaining contract value and offsets the risk of retaining staff.
  • Flexible changes – Change is a theme that runs strong through the veins of Agile software delivery. We expect to not know everything we need to make a product successful from the outset. So, we promote change, based on relevant data and feedback, to ensure that the right product is delivered. At the end of an iteration, changes can be swapped out for old features no longer deemed necessary or a priority. As long as the change is of equal value, there is no further cost. If the change is of lower value, additional work can be identified or pulled forward from the remaining backlog. This clause is valid as long as the project team and customer have maintained a strong, trusting and close working collaborative relationship throughout the project.
  • Additional work – Through the life of a project, more features may be identified that would not be achievable under the existing fixed price contract. For this scenario, either additional newly priced work packages can be added to the end of the project or revert to time and materials.
  • Ranged estimates – There are two ways that estimates can be ranged in an Agile project contract: a range of duration or a range of features. A range of duration allows for an estimate to say that the project or work package will take 12 to 16 weeks for a given set of scope. However, adding duration adds cost as you keep project team members for longer, or it means they can’t be released to work on other development projects. At Toptal, we prefer to range features across a range of story points, keeping the scope as the variable but promising to deliver a minimum level of value to the customer within the fixed time frame of the work package or overall project.

It’s worth remembering that you can always add more scope later. Perhaps you’ve started to earn revenue, you’ve increased users or reduced costs. Either way, it’s much easier to ask for more money and time if you’ve already demonstrated a return or improvement and are delivering business value.

Agile Contracts

Our approach to software costs and pricing

At Toptal we work closely with our customers and engineers to employ techniques that promote stakeholder confidence in project duration and costs. We work at continually elaborating and adapting planning from an initial high level down to more granular detail when it is appropriate and necessary to avoid waste and to enable managed change.

The following steps are taken in elaborating an estimate and fixed price project:

1. Initial high level scope

At the outset of a project, we know least about it’s eventual outcome. It’s folly to imagine it’s possible to know exactly what features our customers and users need from the beginning.

So, we start with a project charter and a high level set of “epic” features that guide the direction of the project, based on a sound vision and objectives

a. Vision and Objective setting What do we need to build ? What do you need to achieve and what are your business objectives? Understanding these questions allows us to set the scale of the project. Do you need a prototype to test an initial idea, concept or technology? Have you identified a clear proposition that has been tested with your market and are you ready to build your first Minimal Viable Product (MVP)? Or, are you scaling your existing business or product to take it to the next level?

b. High level “epic” features Without going into too much detail, you’ll want to define the features that your product has to fulfil your customer’s needs. This is a structured “shopping list” that describes the bare bones of your product; often these are referred to as “User Stories” or epics

c. MoSCoW analysis MoSCoW analysis is a technique that, put simply, helps to identify what is really necessary to make the product viable and what is a nice to have. Those that are identified as a “Must” satisfy what will encourage users to engage and adopt your product. Those features identified as a “Should” will surprise and delight your customers but could be built later. The “Could” items often add no significant business value, may not increase the return and are the lowest of your priorities. The “Won’t” features could well be important one day but are out of scope for this project iteration. However, identifying these now can help to set in mind the potential scale and size of the product for the future.

MSCW

2. Proposal

To make a decision on whether to proceed with a project, it’s necessary to base that decision on well informed data: cost and duration. These are the minimums you need to ask yourself: What will it take to create the product we want ? When can we launch? Does this align with our business strategy and finances?

With the details above, we’re in a position to provide a proposal. Our engineers are handpicked for the specific project requirements and work together with a project manager to derive at least one technical solution, an estimated duration that delivers the known scope and an estimated cost to complete the project.

As we mentioned before, at the outset of a project we know least about what will be delivered. We deliberately keep the features and scope vague, since to do otherwise suggests we know exactly what is required. An estimate at this stage would be the least accurate, but gives guidance on whether it’s worth proceeding with the project.

The proposal is the first tool in elaborating the duration and cost of a project. Once a proposal is accepted, we can move forward to provide a fixed priced quote.

3. Release Planning

The next level of estimate elaboration is to create a release plan that will deliver a range of features in a given timeframe. We derive this from a list of features, the size of the project, how quickly our team can develop quality software that meets a customer’s expectations and techniques for managing the risk of uncertainty.

a. Product Backlog The product backlog is simply an ordered list of “Epics” or “User Stories” that represents the features required for a product. This list starts life as the epics discussed earlier, but between the assigned project team, project manager and customer, we now break these down into more meaningful items. Each of the items represents a portion of business value to the customer. We don’t go into more detail at this stage, we don’t need to know the acceptance criteria, we don’t need to know if a button is blue or green, we just need to know there’s a button that allows some task to be performed.

b. Estimation Now that we have our list of features described as user stories, the team estimate these discrete items of features using a technique called “Planning Poker.” This is a useful technique that ensures quick, reliable results based on expert opinion and analogous sizing. Planning Poker assigns an agreed number to each item representing its size and complexity. This is called a story point. Other Agile estimationtechniques and sizes, such as ‘ideal days’, are available.

The end of this process will determine the size of the project and dependencies between features. The size is determined by adding up all the story points from the items in the product backlog. If that number equals 120, then the size of our project is 120 story points.

c. Prioritisation Now that we have a backlog and a size for the project, we’re in a position to prioritise it with the customer. This is really about identifying what is most valuable to the customer in order to achieve the desired results. The item at the top of the list is considered the most important, the second item is less important than the first, and so on through the list. No two items can be as important as another, each item’s priority is of relative importance or value to each of the other items.

This approach to prioritisation is an important milestone in planning a software project. We now know what is important to the customer and in which order to complete work, taking care of dependencies, to deliver a product that meets expectations.

d. Release Planning To date, we’ve determined what we believe the product to be and how big it is.

Now, we determine how long it will take to deliver a releasable product. The customer and team, including the designers, engineers, testers, scrum master and project manager, work together to identify what can be achieved and how quickly work can be done to create a release plan.

The release plan also gives insight into how the project will align with a customer’s strategic plans.

And finally, this plan ensures the project team has a guiding light that leads the way and defines a logical endpoint to development.

Before we start, we ensure we understand the agreed definition of “done.” This is a given set of criteria that a customer will accept as complete and also meets all of the engineering requirements to be considered releasable.

To take a basic scenario, we take the total number of story points we got from sizing our backlog and divide that by our teams anticipated velocity. (NB velocity is normally expressed as a range, but for simplicity we’ll use a single number here.) We work in two week iterations so our velocity will be reflected by how much we can complete in a two week cycle with the available capacity of the team. If our story points totalled 120 and we anticipate completing 20 points per iteration, the total development duration would be 12 weeks or 6 iterations. We add to that a sprint 0 of 2 weeks and a release preparation sprint of two weeks. In total, our project length is 16 weeks. There are techniques we can use that would help build an appropriate risk buffer into our planning, which we’ll discuss later. But in short, we use the buffer to manage the risk of uncertainty and to come to a minimum agreement of expected story points to be delivered. The outcome might be a range of 90 to 150 story points delivered, 90 being the minimum that would be acceptable to create a viable product.

Agile Planning

Alternatively, if the project must be complete by a given date, in say 10 weeks, the team would determine how much of the backlog can be completed in that time. If we anticipate 20 story points per sprint, plus Sprint 0 and a release sprint, we would be targeting 60 points completed by the end of the project. Again, we would look to manage risk by adding an appropriate buffer, which might result in a target of 45 to 75 story points completed and ready to release. The 45 story points would align with the minimum acceptable to deliver a viable and valuable product. This is one scenario where you might expect to add a team member to increase velocity, if appropriate.

Of course, all of the above is supported by good quality communication and collaboration between all parties to derive a release plan that is achievable, realistic and acceptable to the customer.

4. Fixed Price Contract

Once a release plan is agreed upon, we’re able to create a quote for a fixed price project contract. As mentioned previously, it’s advisable to keep the project duration and team fixed and the scope variable.

The quote for a fixed price contract is delivered along with a statement of work and agreed payment schedule.

As long as there is trust, communication, collaboration and a readiness to enter into the spirit of an Agile software project, all of the steps above allow us to deliver a quote with a realistic degree of confidence that a project will be delivered on time and on budget. Of course, there will be occasions where a project is delivered early or late and we deal with these variations with the utmost transparency.

Estimation Techniques

Agile planning and estimation is supported by a number of techniques that a development team can use to gain confidence in their size, effort, duration and cost. Here are some of the ones our teams use to estimate the size and cost of a software project.

Estimating Size

The size of the project is really an appreciation of its scope, complexity, dimensions, risk and magnitude. To use an analogy, it’s about understanding if we’re building the Eiffel tower or the Great Wall of China. The Eiffel tower is a tall, heavy, complex structure built in a tight urban environment. The Great Wall of China is a relatively simple, but long and sturdy structure spanning many miles of undulating terrain.

Whilst they would both be big projects to deliver, their scope, complexity, dimensions, magnitude and therefore size are different.

It’s important to manage expectations with estimates. They are never predictions, commitments or guarantees. When discussing total size, total duration and total cost, we always work within ranges, so as to mitigate risk, uncertainty and unknowns.

Stories that represent features of your product are individually sized and estimated using story points or ideal days. The total number of these units defines the total size of the project.

Story Points

Story points are a unit of measure that expresses the overall size of a user story. The size of a story, when estimated, includes all aspects of design, engineering, testing, code review, integration, etc.

Each size of a story is relative to another story. So for example, Story A may be sized as one point, Story B as two points and Story C as three points. Here, Story C is at least three times the size of Story A and at least half as big again as story B.

If the following stories in our product backlog have the associated sizes:

Story Size
A 1
B 5
C 3
D 1
E 2

The total size of the project is 12 story points.

Ideal Days

This is a measure of size expressed in days. It removes the concept of overheads such as interruptions, agile planning activities, reading emails and other non-project activities. It only concentrates on how long it would take if you were to work on something continuously without interruption, rather than the elapsed time from start to finish.

Typically, when estimating at a high level when we know least about a project, we would estimate in ideal days as this is an easier concept to correlate with past history and experience than an abstract number such as a story point. Especially when stories at a high level are more epics in nature with little detail and possibly containing additional elements when broken down at a later date.

When estimating at a more granular level, say a story in an established product backlog, either approach may be used and would be decided upon by the engineering team. There are benefits to both approaches and each team will have it’s preference.

Techniques for Estimating

Shared Estimates Estimates are not carried out in isolation. They are performed collaboratively by the whole engineering team together and include design, database, server, front end UI, QA and other cross functional experts. This avoids problems of not considering all aspects of the work involved to complete a feature, and ensures that no one person has the burden or misfortune of over or underestimating the size of a feature. The combined team will all have a view that can be discussed and agreed upon.

Analogous Estimates This is where we consider two discrete features and decide that one is relatively smaller or bigger than the other. We can look at a given story and agree that it is small in size, and if using story points we might give it a size of two. The next story might be considered as large compared to the first, and we would give it a size of five. This suggests that a large is at least twice the size of a small feature.

We would continue this exercise with all the stories. Once complete, we can then lay all the small, medium, large and extra large stories side by side and cross check our sizing to ensure there is a level of uniformity in our estimation.

Planning Poker Much has been written about Planning Poker; I also mentioned it in my previous blog. One of the best resources to understanding it is here.

In essence it combines expert opinion, analogy and team collaboration into one easy, fast and reliable process.

It brings together multiple experts who are best suited to build an estimate based on technical and domain experience, a lively dialogue and sound justification.

Chat

Velocity

Velocity is a measure of a team’s capacity to get work done in a given iteration (or sprint).

It is expressed as a range, for example 23 to 32 story points per sprint, especially early on in a project’s life. Generally, this is because unless the same team has worked before on the same problem, it is hard to depict exactly what the team’s velocity will be. Notice, we refer to a team’s velocity and not an individual’s!

We use velocity to plan our releases and adapt our plans and work packages as we progress through a project, thus enabling us to adjust our forecast for completion regularly and accurately through execution.

When we start out, we are forced to define a range of velocity with very little data. We can use historical values, if the team and problem space are the same, which is often least likely. We can run an iteration to get an idea of velocity from a team actually working on the project, but this is costly and doesn’t work if decisions are still to be made on agreeing to start a project. Or, we can make a forecast.

Forecasting a velocity involves taking a sprints worth of stories and splitting them into tasks that are performed to complete the story. We would estimate the number of hours each task will take, which includes design, development, testing, and so on, and assess how much capacity the team would have in a given sprint. A capacity of 70 percent for an unencumbered team is a good baseline. So, in a simple situation, if the total hours available to the team is:

  • 4 team members * two weeks * 40hrs per week = 320 hours
  • Multiplied by our 70 percent capacity = 224 hours
  • Add up all the feature tasks and stop counting at 224
  • Take all the completed features, add up their story points and you get your velocity, say 36
  • Apply 20 percent either side to get a range of the lowest and highest, to arrive at an estimated velocity of 29 to 43 story points.

Velocity usually varies in the first two to four iterations and then stabilises within a small range of points. So, where our initial range before sprint one was 29 to 43, by sprint four, it may plateau to 34 to 38. This then gives us greater confidence in forecasting our final completion date.

Buffering Plans for Risk & Uncertainty

All software projects come laced with a level of uncertainty. That uncertainty becomes less as we progress through the project and more is known about our technology, environment, performance and the needs of the customer and users.

We mitigate this uncertainty or risk with a buffer in the schedule, which accounts for a margin of error in our estimation and the unknowns we cannot determine before development starts.

Typically, there are two buffer types: Feature and Schedule. As we’re often defining a fixed price for a fixed delivery date, it’s preferable to use the Feature buffer.

This approach gives us a credible risk mitigation strategy and gives a customer confidence in what they should expect to see as an outcome when the project is complete.

Feature Buffers

With a feature buffer, we are forecasting that we will deliver a given set of features but will ideally complete a further set of features. This should reflect at least the minimum feature set that the customer considers necessary to launch a viable product, but more may be delivered within the time frame if all the various internal and external influences allow it.

So, a customer may decide that the highest priority features from the product backlog, adding up to 100 story points, are most important. They then may consider additional features that add up to a further 30 story points. The team therefore will plan based on delivering 130 story points, with the minimum of a 100 being completed by the end of the scheduled completion date for the given fixed price contract.

Some closing thoughts

Agile can be a very difficult concept to fully grasp and adopt. This is no less true when managing sensitive topics such as price, scope and duration. Unfortunately, I know first hand that demanding clients want all things fixed up front and are eager to blame the supplier when it all starts to unravel. Equally, I’m aware of vendors that dig their heels in, become unresponsive and fail to respond to customer needs. Taking an Agile path is fundamentally built on trust, good relationships and stellar communication. These must be values held by both parties in order to maintain a healthy project for the equal benefit, satisfaction and success for all involved. Keeping an open mind and constructive attitude to collaboration and negotiation is the best way to avoid relationships going sour.

I’ve worked with clients that have found it hard to embrace the adaptive nature of Agile and to relinquish a command-and-control attitude. It’s hard to let go and put all your faith and trust in a team you don’t know. Often, clients may wish to create all the requirements up front as a specification of what will be delivered. This gives them a feeling of confidence that the scope of a project is well-defined. But ultimately, this fails to materialise as a successful approach. If we’re locked down to scope and unrealistic demands in a contract, problems arise very quickly.

We know, when taking this approach in traditional methods, that scope changes, unknowns are uncovered or what we thought the customer wanted is no longer true or way off the mark. Taking an adaptive approach to pricing, planning and scope allows customers to truly identify their product to be exactly what their market needs. It enables a vendor to be responsive, imaginative and efficient too. Harnessing collaboration between customer and vendor over contract negotiation is key.

Vendors need to be honest and customers need to be realistic about what can be achieved from the outset. A vendor that promises unrealistic targets and then increases costs may win the initial contract, but will soon lose favour from a disgruntled customer. Too often, relationships break down due to a lack of trust or confidence between parties. Trust must be built from the outset and maintained throughout the course of a project. A vendor must be flexible and cooperate with changing needs. Customers always want more; it’s a natural consequence of doing business. There must be a an equal and beneficial value exchange between both sides. For customers, they’re looking to create value for their business. For vendors, they should be looking to create value by forming long-lasting relationships with customers. Observing the Agile Manifesto’s values and guiding principles is a sound basis for forming strong, balanced and long relationships.

Summary

I hope this has given you some insight into planning, estimating and defining a price for an Agile software project. All of the approaches and techniques above are designed to build trust in a team and to build confidence in customers’ minds on how long and how much it will take to build a software product. And ultimately, to build confidence in making a decision to proceed.

Follow these guidelines and you’ll be sure to find a satisfactory route to bring your software product to life.

More insights await at the virtual Agile and Scrum conference, going live on May 4th. 5 keynotes and 20 sessions to choose from, plus networking and PDUs/SEU®s.


Can Microsoft® Project Be Used for Agile Projects?

By Keith Wilson, B.Comm., PMP, MCT, MCTS  |  Senior Trainer and Consultant, IIL 

Can Microsoft Project be used for Agile projects? Yes! Customizable fields and custom groups can be used effectively to create an Agile template. Custom fields allow you to add project-specific information, which can be used to filter or group tasks to provide different views into the Agile schedule. It is possible to create a schedule for planning, communicating, and tracking Agile projects, or with an Agile or a hybrid method.

Key characteristics of the Agile development method are Iterative, Incremental, Embraces change and Delivers a deployable product early for a quick ROI.

img1

Agile teams deliver complete and functioning code within short iterations. During the iterations, all of the necessary work to take features from an idea to a working product is completed without artificial dependencies that prevent work from being done in parallel. The end result is that portions of the product are delivered on a regular and frequent basis. This gives stakeholders a much better idea of the state of the project, because they can see and use the end result as it becomes available.

The strengths of Agile development:

  • Delivers minimum usable subset
  • Delivers on time and to cost
  • Iterative development for evolving solution
  • Flexible processes
  • Collaboration of whole team

So what project-specific data must be added to create an Agile schedule?

An Agile project starts with a backlog, which is a list of features to be implemented, and a number of iterations or sprints to implement those features, which are represented as tasks in the schedule.

In addition, each feature will have a priority and a size estimate represented in story points and will be mapped to a sprint. Story points (which can be numbers – e.g., 1, 2, 5, 8) are relative values based on the size or difficulty of a user story relative to other stories. When you estimate using story points, you estimate the “bigness” of a user story compared to other stories. Each feature and sprint will also require a status (e.g., not started, in progress, or done).

To create an Agile project schedule we need to know:

The duration of each sprint, the release date if there is a planned release including several sprints, the priority of each feature in the backlog, the feature complexity or story point value, user need or priority and state. In addition we will need to know the resources and the percentage of their time available per sprint and each resource loaded labor rate.

We will need to create custom fields for Agile-specific information including:

User Need                   Text Field

Lookup Table: Low, Medium, or High

State                             Text Field

Lookup Table: Not Started, In Progress, or Done

Story Points               Number Field (Estimate of Story Points)

Set Calculation for task and group summary rows to Rollup: Sum

Sprint                            Text Field:

Lookup Table: Backlog and Sprint 1 through Sprint n

It will also be necessary to create two Groups:

Sprint                  Group by Sprint.

The Sprint group will list all features in each Sprint; story point totals roll up for each sprint. Features not assigned to a sprint will be grouped under Backlog.
Burndown         Group by State, then by Sprint.

The Burndown group will provide story point summary by categories: Done, In Progress, and Not Started.
Story point totals roll up.

The Agile schedule will also require two summary tasks: Sprints and Features. Under Sprints, enter the expected number of sprints, including the name and duration of the sprint, and link them in sequential or finish to start order. Then list the features under Features summary task. Make each of the features a milestone, by indicating a zero duration. By default the features will all be in Backlog. To assign a feature to a specific sprint, select the sprint number in the Sprint dropdown. Also, when you assign a feature to a sprint, set a finish-to- start predecessor to that sprint so the expected finish date of each feature will be known. When tracking the project, if one or more features is not completed in a specific sprint, it is easy to just update the sprint number and the predecessor to move those features to another sprint.

Build a resource pool with real or generic resources. Be sure to include a rate per resource and other know attributes such as Calendar, Max Units, Group, and Rate. Once you have the resource sheet complete, assign the resources to each sprint and indicate the percentage of time that they will be working on the Sprint. Since there is a rate per resource, Microsoft Project will multiply the duration by the percentage allocation time for each resource and then by the resource rate. It will then summarize each resource cost per sprint to provide a total cost per sprint, which in turn can be rolled up to show the total cost of the project.

The following is an example of a schedule with sprints that have a duration of 15 and a dozen features and is using the custom Burndown group, grouped by state and sprint. It also displays the total number of story points for each of these states:

img2

Custom fields are a powerful feature of Microsoft Project, and when used with custom groups, we can actually use Microsoft Project for an Agile project without knowing which features each sprint will be addressing. Given the duration of each sprint, the resources, resource rate, and percentage assigned it will be possible to calculate the cost per sprint; and if the sprints are rolled into one release, the total cost and duration for that release or project.

Leave a comment below if you’re interested in receiving a downloadable template.

[trx_infobox style=”regular” closeable=”no” icon=”inherit”]Keith-1

About the Author

Keith Wilson is a Microsoft Project and Project Management Senior Consultant/Trainer for International Institute for Learning, Inc. His background includes over 25 years of successful management and consulting experience, with a focus that includes project management, training, and business planning. Well known for his public speaking skills and enthusiasm, he has been a welcomed facilitator at numerous Fortune 500 corporations, Universities and Associations worldwide.[/trx_infobox]