DevOps Journey: Analyzing the impact of Components to Services (CFIA)

To ensure maximum uptime of services, there is a need to identify the components, resources, and configurations that enable the smooth operation of the service. IT systems and their configurations are growing in complexity as more services, components, and people are added into the mix.

To map out the relationships of services to other services or components, I use the Component Failure Impact Analysis (CFIA) matrix. In the event that a particular component (or configuration item) should fail, the CFIA Matrix helps me determine the potential impact on service delivery.

CFIA is a visual tabular view of services and their component items. It is part of a proactive Availability Management process. With this visual matrix, the IT decision makers of your organization can optimize the capability and capacity of the IT Infrastructure and resources. It can also identify high-risk components where the failure of those components will impact many inter-dependent services. It is a useful tool to justify upgrade or purchase of IT components.

How do you start with CFIA?

Given a service, identify the components that the service is dependent on. Determine the impact of your IT components on the service based on your pre-defined levels. Impact level can be 1) DOWNTIME(X), 2) WARNING(O) where the service is still operational but with reduced capability, or 3) NO IMPACT(Blank Space). Start with the basic services, then build up the list as you identify more components, services, and resources.

CFIA

With the above illustration, it is easier to determine the relationships of the services, components, and resources.

Visit our download page to get a copy of the CFIA (Component Failure Impact Analysis) Matrix Template.

– agilepinoy

Advertisements

DevOps Journey: Service Monitoring – Learning from Service Failures

Coming from a Development background, there are several concepts that you need to learn in your journey to become a DevOps engineer. You need to be familiar with the operation side of things.

Being Developers, you are more concerned with ensuring your code works according to the acceptance criteria and the definition of done.

In ITIL, the set of features and functionality are called UTILITY.
UTILITY: Fit to purpose, or utility, means that service must fulfill the customer needs. It is summarized as what the system does.

The value of your software won’t be realized until it is ‘Fit for Use’.

In ITIL, the set of qualities that define ‘Fit for Use’ are called WARRANTY. In Operation side of things, IT Operators are not only concerned with UTILITY but also WARRANTY.
WARRANTY: Fit for Use is a promise or guarantee that a product or a service will meet its agreed purpose by being available when needed, with enough capacity, and dependable security.

In this article, I will discuss the reliability attribute and how each service failure can serve as an opportunity to continuously increase your skill as DevOps engineer.

To maximize the up-time of your services and keep disruptions to a minimum, reliability metrics (failure metrics) should be tracked. Tracking the reliability of services is a challenge when you do not have automated CMMS (Computerized Maintenance Management Systems). I provided a simple excel tracking template to track the services you deployed. (see Download Page: look for Service Monitoring-Sheet for IT Managers/DevOps).

As soon as your software is deployed to production, you will encounter several error conditions that are not in your test matrix!
Deployment issues, that are rarely considered by developers with minimal delivery experience, will occur. Best to track these to continuously improve on the reliability of your services.

Availability and Reliability Metrics

In general, we speak of availability in terms of “nines.”
– Two nines, 99%, allows 3.65 days of downtime per year (100%-99%)*365
– Three nines, 99.9% is about 8 hours of downtime
– Four nines, 99.99% is about 53 minutes of downtime
– Five nines, 99.999% is about 5 minutes of downtime, <– Our BHAG (Big Hairy Audacious Goal)

Downtime is measured from the time of failure until the system is back in operating condition.
<In the given template, this is ‘Monitoring’ Sheet Availability Column.>

In order to increase reliability, failure metrics should be tracked and monitored as well. The common service/device failure metrics are MTTR, MTBF, and MTTF.

1. Mean Time to Recover (Average Downtime)

  • FORMULA: MTTR(Recover) = Total Downtime / Number of Failures
  • It is the goal of IT operators to quickly recover from downtime
  • Mean Time to Recover is from the time when the failure occurs until the service resumes operations

<In the given template, this is ‘Monitoring’ Average Downtime Column>

2. MTTR (Mean Time to Repair – the average time to repair the system)

  • FORMULA: MTTR(repair) = Total Repair Time / Number of Failures
  • It is the goal of IT operators to repair systems at the quickest possible time with minimum cost
  • Mean Time to Repair includes the following time: Repair Time, Testing Period until Return to Normal Operation
  • It does not include point of failure and diagnostics
    <In the given template, this is ‘Monitoring’ MTTR Column>
  • For each downtime, log an incident list to indicate Downtime, Time To Repair and Manhours to Repair
    <In the given template, this is ‘Incident-List’ sheet.>

3. MTBF (Mean Time Before Failure)

  • FORMULA: MTBF = Total Operation time/number of failures
  • The goal is to have longer operation hours before failure occurs through effective preventive maintenance
  • Mean Time Before Failure does not account times when servers are down for maintenance
  • It is the average time between failures

<In the given template, this is ‘Monitoring’ MTBR.>

4. MTTF (Mean Time to Failure)

  • These are for measuring the reliability of equipment that is not repairable. Example of these are light bulbs, memory modules
  • Simply put, this is a measure of the lifespan of a device (Device Starts working -> Device Failure Occurs)
  • FORMULA: MTTF = Sum of all units hours of operation / total number of units
  • This metric, although not included in the template, is useful when the operators need to estimate how long a component would last as part of a larger piece of equipment that they maintain

Logging the above metrics with historical information on how each incident occur, their root cause, corrective actions, and preventive actions will continuously improve the reliability of your systems. While this article is mainly learning from your past incidents, it is recommended that you build reliable systems upfront through resilient architecture using a fully reliable infrastructure.

– Agile Pinoy

Requirement’s Journey: Illustrated

As a supplement to Scrum Exoskeleton from scrum.org,

Scrum Framework

I use the illustration below to map the journey of a requirement from their sources to their deployed form. My teams use this to describe the flow of value and to easily determine what activities they should perform to complete a requirement.

RequirementJourney

The flow of requirement to a working product passes through filters,

Filter 1: The Product Vision Test

Requirements should pass the Product Vision test before it is considered to be included in the Product Backlog

  • Are the WHYs and the WHATs of the requirement clear?
  • Does the requirement contribute to the product vision?
  • Does it add value (benefit, risk reduction or opportunity enhancers)?

When all the answers are YES, the Product Owner will write the related Epic/ Themes to the Product backlog. Else, the requirement should be removed.

Filter 2: Definition of Ready

Before a requirement is considered for implementation, it should pass the Definition of Ready. This will vary from team to team. At the minimum it should be:

  • CLEAR: everyone understands the WHAT and the WHY of the Product Backlog item
  • SMALL: the product backlog item can be implemented in 1 sprint that complies with the definition of Done
  • TESTABLE: acceptance criteria can be defined

The themes or epics from Filter 1 should be broken down, decomposed, and refined. I prefer user journey mapping technique to identify user stories of a given requirement. The output of this filter are READY user stories.

For more information about Product Backlog Refinement, please refer to my previous article, Everything about Product Backlog Refinement.

Filter 3: Sprint Planning

READY Product backlog items are selected for implementation during Sprint Planning. The selection will depend on its prioritization (as influenced by the Product Roadmap) and its relevance to the current sprint goal.

The User Stories are decomposed further into tasks and as a whole monitored in the Sprint Backlog.

To assert the acceptance criteria, I prefer that User Story acceptance tests are written and executed in a BDD (Behavior-Driven Development) environment. Unit testing are performed through TDD (Test-Driven Development) and executed daily through a Continuous Integration Environment.

Filter 4: Acceptance Criteria and Definition of Done

A User Story is considered to be DONE when it passes its acceptance criteria and its Definition of Done. The Development Team should not wait for the Sprint Review to validate the DONENESS of User Stories. They should ask the P.O. or her representative to confirm User Story completeness.

For more information about Definition of Done, please refer to my previous article, Everything about Definition of Done.

Filter 5: Sprint Review

During the Sprint Review, the Product Owner, from the inputs of the stakeholders decide whether the completed story should be included in the Increment or placed back to the product backlog for further enhancement.

Filter 6: Release Decision

Not all increments are immediately released for deployment. It is a business decision decided by the Product Owner.

When the Product Owner decides to release the increment (cumulative done stories including those stories not previously released), DevOps/Continuous Delivery release cycle is executed to deploy the release into production.

When the product is deployed, new requirements and defects are discovered. These requirements go through the same Journey (Funnels) .

– Agile Pinoy

What makes a great Agile Retrospective?

I asked the Agile Philippines community through the Agile Philippines Facebook Group on tips for effective and fun retrospectives the Filipino way. These are my key take aways.

1. Great retrospectives are affirmative

  • Facilitators set the tone to make the retrospective a safe environment to constructively discuss improvement areas in the previous sprint
  • Members find retrospectives as the safest avenues where they can share their thoughts, feelings, and observations
  • Facilitators know that people do not intend to work poorly, the aim of the retrospective is to build environment for sustainable operation and growth. It is not a fault-finding nor a blame-throwing event.
  • The teams can have a “round-table of gratitude”, everyone gets to thank someone in front of the team

2. Great retrospectives are celebrations

  • Organizers recognize the people who contributed most for the success of the current sprint by giving out small tokens or rewards (like Golden Duck Awards)
  • The team can celebrate learning through the celebration grid by categorizing learning into 3 buckets: good practices (high probability of success), mistakes (doomed to fail from the beginning but done nonetheless) and experiments (learning is the highest here)
  • The team knows that regardless of what they discover, they understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

3. Great retrospectives are fun

  • There are at least 32 ways on how to do fun retrospectives. See Fun Retrospective for activities and ideas for making agile retrospectives more engaging

4. Great retrospectives have dynamic facilitators

  • Sometimes the facilitator after reiterating the rules and the games of retrospective, can just go back and see the results – self-organization in action
  • Facilitators do not act like a boss directing the discussion, they act as friends, and colleagues who listen, who understand, recommend and not prescribe.
  • Facilitators have Retrospective Exercise Toolbox. In their book, “Getting Value out of Agile Retrospectives: Toolbox for Retrospective Exercises”, Luis Goncalves and Ben Linders detailed out retrospective exercises and when to effectively use them.

5. Great retrospectives are team-builders

  • Retrospectives are team exercises and not for general consumption so as not to hinder with openness and honesty
  • Members should avoid making the retrospectives as gripe/complain sessions, people will get defensive and will hinder effective collaboration.
  • Retrospectives are opportunities to break barriers to effective sharing
  • Retrospectives facilitate self-organization, the team can try to do other methods in the next sprint, they are the ones to correct their own processes. The team takes control of their own Agile improvement JOURNEY. There is a high buy in the improvement effort.

As an end note from the experienced members of the group, we must remember that the purpose of retrospective is to learn from the past to improve the future. There are lots of game play but productivity may get lost in the fun and the games will distract the members from purpose. Great retrospectives are deliberate and intentional.

Thank you Agile Philippines!

Everything about Project Owner Responsibilities

When I help teams transition from traditional project manager-led projects to Scrum, the members are confused with the new roles. We will map out existing roles and their equivalent roles to Scrum with some customization to adapt to the Team’s culture.

Before the team can map this, they need to understand the responsibilities of each role. So I show them the list of all the responsibilities of each role and explain to the team item per item so they will know what to expect from each other. In this blog post, I shall dump Everything about the Product Owner Responsibilities – instead of the team reading all the articles about Product Owner.

Product Owner’s Responsibility to the Product

  • I have a compelling vision of the product
  • I have an elevator pitch (a tagline) for the product vision that is easy to recall
  • I create the business model for the product or service: a business model is plan for the successful operation of a business, identifying sources of revenue, the intended customer base, products, and details of financing.
  • I am expertly aware of the marketplace for the product and constantly collect information about the marketplace in order to maximize the value of the product
  • I have a product roadmap for at least 6 months out (depends on the planning cycle of your company)
  • I decide when to release an increment to the market while understanding the risk of getting out of sync with the market when releases are too far apart
  • I deliver the products iteratively and incrementally, maximizing opportunity for feedback
  • I have a product backlog that is ordered (prioritized) based on value, risk, dependencies, criticality – or whatever criteria I set that is easily understood by all
  • I have the authority to make decisions on the product backlog
  • I am responsible for the finances of the product/project; I decide the priority to provide the best return on investment (risk/return/budget)
  • I make sure that Product Backlog items have description, order, estimate, and value
  • I have a product backlog with sufficient READY items for sprint planning (at least for 2 sprints). More details at the top and less details at the bottom.
  • I regularly refine the product backlog with developers and should not take more than 10% of their time
  • I make sure that product backlog items at the top satisfy the INVEST criteria
  • I maximize value by eliminating waste (lean concepts) in the backlog and in the process
  • I update the product backlog at least after the Sprint Review to capture stakeholder’s feedback
  • I understand the concept of technical debt and actively prevent them

Product Owner’s Responsibility to the Stakeholders

  • I make sure that the product vision is aligned with business objectives
  • I get stakeholder buy-in on the product vision, I make sure that I get their TRUST
  • I know who my stakeholders are, I spend majority of my time communicating with them
  • I am the Lead Facilitator of stakeholder involvement
  • I make sure that the product backlog is visible to all stakeholders
  • I understand the needs of my stakeholders and manage their expectations (Tools: Salience Model, Power Influence Grid)
  • I invite the relevant stakeholders in the Sprint Review. I get stakeholders’ feedback of the latest increment and update the product backlog accordingly
  • Equipped with knowledge of the market and the stakeholders, I can anticipate stakeholder’s need and visualize them (Tool: customer journey mapping)
  • I am the primary liaison between the stakeholder and the team

Product Owner’s Responsibility to the Team

  • I communicate the product vision to the team often and early
  • I am available to the team to clarify requirements and to answer their questions on the requirements
  • I inspire the team and help them feel a sense of purpose through the product vision
    • I make them understand how the work they are doing helps the customer and how it fits into the company strategy
  • I am the team’s ultimate authority on work prioritization and the decision maker on what is in and what is out.
  • I motivate my team by teaching them about the domain, helping them understand the problem space. I make them write and analyze user stories.
  • I agree with the team’s Definition of Done and work with the team to continuously improve quality
  • I am available to validate and accept user stories as the team completes them (ideally within 24 hours)
  • I make sure that the user stories have acceptance criteria before the team works on it in the sprint
  • I actively negotiate and clarify user stories with the team during sprint planning
  • I have agreed upon Definition of Ready to know when a user story can be pulled from the product backlog to sprint backlog
  • I participate in the Sprint planning
    • To set the business goal for the sprint, the backlog items that will meet them
    • Together with the team set the Sprint Goal
    • To inspect How to the work will be achieved as planned by the development team
  • I host the Sprint Review, inspect the increment and adapt the product backlog
  • I participate in the retrospective to improve my work as a Product Owner
  • I actively reduce the work in progress and strive to limit the amount of multi-tasking
  • I can cancel the Sprint when the Sprint Goal no longer makes sense while taking into account the impact in productivity of canceling sprints.
  • I empower the Development Team with a decision-making framework that enables them to make decisions
  • I protect the team from distractions so they can focus on the Sprint Goal

Product Owner’s Responsibility to the Scrum Master

  • I have a strong partnership with the Scrum Master, she is free and comfortable to correct me when my words and values are not consistent with Scrum
  • I constantly work together with the Scrum Master to improve our collaboration and cooperation
  • Together with the Scrum Master, we establish an environment for sustainable development where the team can work at a consistent pace indefinitely
  • Together with the Scrum Master, we actively avoid delays in the process (we understand delays can trickle down)

I will regularly update this list as I learn new materials. Please do let me know through the comments if miss an important responsibility.

Planning to get certified as Scrum Professional Product Owner? Check my PSPO reviewers.

– Agile Pinoy

Agile Chartering: How to successfully launch an Agile Team

The Project Charter

When I was training for PMP®, our instructor kept on stressing the importance of a Project Charter. A Project Charter is a formal document within the organization that recognizes the existence of the project and defines the authority of the Project Manager to carry out the project, within certain constraints to completion.

Often, in the context of offshore development, projects are initiated when the contracts are handed from the Sales Team or PMO to the Development Team. The Development Team will have little room to organize and launch effectively. The Development Team will have to meet those contractual obligations agreed by the people “upstairs”.

Having a formal project chartering process in your company will help facilitate

  • Alignment : The Project Charter can serve as the focal point throughout the project, it serves as the baseline for scope management. It enables shared understanding.
  • Authorization : empowers the Project Manager and the Project Members to carry out the project to completion; ensures that key stakeholders are aware of the project; secures budget and resources for the project
  • Accountability : it highlights major risks and issues surrounding the project; defines the roles and responsibilities of key stakeholders; sets the end date, milestones and the success criteria.

A Project Charter should at least contain,

  • Purpose: Business need to address, why the project exists
  • Project Objectives and Related Success Criteria: Measurable criteria for the success of the project that are visible by external observation
  • Scope/High Level Requirements: Defines what is in and what is out. High-level Features documents the boundaries of the project
  • High Level Risks and Assumptions: Risks are uncertain events that will highly affect project objectives, while assumptions are assumed true for the purposes of planning
  • High Level Constraints: limitations imposed on the project such as business constraints or technical constraints
  • Milestone Schedule: events in the project timeline usually marked by the completion of a deliverable or goal.
  • Budget Summary:  funding of the project in terms of money, material and/or effort
  • Project Organization: Who are the key persons accountable to the project – Project Sponsor, Project Manager, may include the Product Owner and the Scrum Master

To start you off with Project Chartering, here is a simple template <to be provided soon>.

The Agile Chartering

Which came first, the project or the team? Like the chicken or egg analogy, this is highly debatable. But I like to favor the creation and establishment of the team first before the assignment of resources to the projects. In Jim Collins in his book Good to Great emphasizes on getting the “Right People on the Bus” — first who, then what.

The essence of Agile is to have small, flexible and high-performing teams.

Teams undergo stages of group development (based on the Tuckman Ladder) before they become high-performers:

  • Forming: The team meets and learns about the opportunities and challenges, and then agrees on goals and begins to tackle the project or task. The members put on their best faces during this stages.
  • Storming:  The team starts to sort itself out and gain each other’s trust. Individuals will voice out their opinions and may result to conflicts among the members. Normally tension, struggle and sometimes arguments occur as people sort out how they will work together.
  • Norming: Individuals will start tolerating the individual working styles and views of other members. The team becomes self-aware that they need to settle their differences and personality clashes in order to meet the common goal and to stay ahead of the game.
  • Performing (productive stage): The team members perform as a UNIT, they are autonomous. Where value flows with minimal friction among the members. They self-organize to meet the situation at hand and invest in each other’s strengths and complement each other’s weaknesses.
  • Adjourning: Is when the team is dissolved and individual members are transitioned to other team/effort.

Every time there is a change in team composition, the team undergoes the same stage (may be minimal than building the team for the first time).  I recommend that when a team reaches the performing level, instead of disbanding them at the end of the project to join other project team, assign new projects/opportunities to the whole team. This is more cost-effective than creating a new team around the new project or opportunity.

With high performing teams, the organization already laid the ground-works for a successful execution of projects.

What is Agile Chartering?

Better teams create better outcomes. Agile Chartering enables teams to liftoff for
success by co-creating a shared view on purpose, alignment and context.

The Book, Liftoff – Launching Agile Teams & Projects by Diana Larsen and Ainsley Nies, talks about launching a team towards success.

Agile chartering gives all stakeholders a voice and the opportunity to co-create a common understanding of the project dynamics, its purpose and context. It
creates co-ownership of the project within the project team and thereby higher commitment to the project goals.

The three main dimensions of Agile Chartering are:

  • Purpose: The team revises the initial purpose statement and works out project vision, mission, and mission tests. In the VISION, when the product is already with the users – how the product will change their world? What does success look like? The Agile Inception Deck is a great technique to get the team in the same Page (Why we are here? what we’re trying to do? How are we going to get there? Why are we building the product? – the drivers).
  • Alignment: The team works out the values and principles of the project and it clearly defines who are in the core team. Alignment connects the purpose and the context. It identifies the values and principles, the working agreements and simple rules (house rules).
  • Context: The team figures out what the boundaries of the group are, how and with whom they will have to interact and does some risk and prospective analysis.

The outcome of an Agile Chartering discussion (workshop) is not a final document. It will always be in a draft state and must be revised on a regular basis by the team, whenever the project or team changes or learns something new.

The Agile Charter is the foundation upon which all of the team’s work, rules, tools, and behaviors are built. Unlike traditional project management, where a charter defines the project scope and success criteria, often pre-determined by senior management, an Agile Team Charter is built and agreed upon by the team exclusively. This will facilitate buy-in from the team members. When team members are able to directly contribute to and influence a project, they will be much more motivated for success.

An Agile Team Charter should contain

  • Vision: Why are we here?
  • Mission: What are we trying to do?
  • Success Criteria: What will success look like? What are visible external factors that can show that we are going in the right direction? What are the learning milestones?
  • Project Team: Who are the people in the CORE team (and their roles) – Scrum Master, Product Owner, Developer
  • Rules of Conduct: What are the rules of conduct? What principles do we live by as a team? What are the working agreements? How will conflicts be resolved?
  • Communication/Other House Rules: What are the events, their specified period, place and attendees? What information will be shared, how, where, when? How will we collaborate?

Below is a sample of a team charter. Proceed to the Download Page to download the Agile Team Project Charter template.

agile-chartering

Since the team charter enables bonding of the team, it is important that the Team Charter be readily available or prominently posted so all team members have immediate access to it – let’s say in your Project Wiki or Landing pages.

Conclusion

For a highly successful project, both Project Charter and the Agile Team Charter are needed. The Project Charter provides authorization, alignment and accountability among stakeholders (internal and external) the project and the Agile Team Charter enables the team to become high performers and take ownership of the project.

One a team is established, instead of disbanding them when the project is completed. Assign new projects or opportunities to them. The basic unit of Agile Development is not the developer, it is the TEAM.

Mabuhay!

– Agile Pinoy

Agile Estimation for Maintenance Projects

In the software outsourcing industry, our usual projects involve upgrading and maintaining existing legacy systems for our clients so that they can focus on new opportunities.

In my early days as a typical Project Manager, I ask for available documentation and work products from the client and begin estimating. Equipped with piles and piles of historical information from previous projects, I size up the scope in terms of LOC, number of pages, or whatever size drivers that represent the deliverables. Then applying the PM Tool called “Expert Judgment” I will choose the relevant estimation rates to get the effort of each deliverable, add some risk factors, and sum them up to get the total cost. Plot this in a Gantt chart and an estimate is produced.

The problem with my previous approach is that documentation is often not available or outdated (or sometimes they are written in foreign language). Each project has unique variables that may not be captured by historical-based estimation. At the end of the project, when the ACTUALS were compared to estimates, the differences were Outliers! There were several adjustments along the way as the team learns more about the project. Contractual adjustments are usually very cumbersome and costly.

Now instead of estimating in silo, I involve my team in exploration and estimation. In agile, estimation is done best by the people who will actually do the work. Below are the steps that we usually follow in coming up with a more confident and relevant estimates:

1. Explore the system to be maintained, build and run it

When NDAs are signed and the parties are free to share information, we ask our clients for an environment where we can execute and explore the software. In cases where environment setup is expensive or is difficult to setup in our site, we arrange for customer visits. We also ask for test accounts for cases when the software is accessible via Internet.

2. Ask for an equivalent product backlog (list of maintenance items)

Deployed software will have change requests, bug list, task list and technical debts. To gain further understanding of the in scope items, we run-through the list with the customer. Here is a simple backlog list. You can download the template at the end of the article.

backlog-01

3. Relatively size-up the product backlog items (using T-Shirt Sizing or complexity scales)

Using the scales in our planning poker cards, we relatively size each product backlog item
-T-Shirt Sizing: XXS(<1point), XS(1pt), S(3pts), M(5pts), L(8pts), XL(13pts), XXL(21pts) or
– Complexity Sizing: NEGLIGIBLE(<1), VERY EASY(1), EASY(3), MEDIUM(5), DIFFICULT(8), VERY DIFFICULT(13), VERY VERY DIFFICULT(21)

backlog-02

4. Spike for an initial velocity

Our team will perform a spike to implement 1 medium-sized (5 points) product backlog item to determine the effort needed. As much as possible, we try complete the product backlog item from end to end (pass an initial definition of done). In case time is limited, we estimate the effort needed to complete the remaining tasks to complete the backlog item. The more spikes we perform, the more accurate our estimation becomes. This will depend on how much effort your company can spent for pre-contract activities. On the example below, 1 medium(5) and 1 small(3) items were implemented in Spikes completed with 23 hours of effort. The computed assumed velocity is 2.88 hrs per point.

initial-velocity
5. Estimate the product backlog

From the empirical data gathered from the spike(s), we revisit the product backlog and re-size the items (change from M to S or from XL to XXL etc.). Using the initial velocity, we can determine the approximate effort per backlog item.

backlog-03

To simplify estimation, I recommend fixed team size across the duration of the project depending on the computed effort and the total duration constraints (if any). For example, assuming a capacity of 150 hours per person per month, to determine the team size of a 1150-hour-3-month project = 1150hrs/3mos/150hrs = 2.55 Fulltime equivalent engineers (RAW team size).

6. Add capacity for Technical Investments and Technical Debts

For a complete estimate, you need to consider the efforts spent on technical investments, technical debts, and other unaccounted tasks/risks.  As my own rule of thumb I add 50% from total Feature points for Technical Investment and 10% for Technical Debts. You may have your own factors. To know more about technical debts and investment, read my blog entry on Technical Investment over Technical Debt.

backlog-04

In the example, I use 2-week sprint. It is my recommended sprint length as I discussed in Everything About Sprint Length.

You can use the figures to fill-up your own organization’s estimation template.

From experience, this type of estimation will take 1 to 2 weeks.  Aside from having a more realistic estimate, we have a chance to immediately work with the customer from day 1 and show them our capability from the results of the spikes. Hopefully will gain their favor in choosing your service as their developer of choice.

Here is the template I used for the samples above: Simple Product Backlog Template

Mabuhay!

– Agile Pinoy