Meeting Acceptance Criteria Implies Customer Satisfaction

checklist

It doesn't matter if your model is Kanban, Agile, Waterfall, or RUP.  You can't close out a project or task without first identifying the Acceptance Criteria.  Acceptance criteria begins to take shape during the first moments of a project or task. If you are utilizing Kanban or Agile, everything pertaining to your deliverable should be captured on your story cards.  This includes story details and acceptance (testing) criteria.  Satisfying all acceptance criteria implies the needs of the customer have been met.

If you following Waterfall, RUP, or similar model, you would expect to identify acceptance criteria, along with scope description and project deliverables, in the project scope statement.  (These are each components of a scope baseline)

It all goes back to requirements and stakeholders' satisfaction.  Remember each requirement should add business value by linking to a business or project objective(s).

Those criteria, including performance requirements and essential conditions, must be met before project deliverables are accepted. Regardless of your model, spare yourself a lot of wasted time AND money by documenting acceptance criteria early.

How To Effectively Manage An Offshore Team Of Developers

There are probably two primary reasons you would go with an offshore team. (1) Your customers are also offshore, or (2) you're hoping to save money on development costs.

I'm going to assume your reason is number (2).  Though this post is brief for such a complicated topic, it should give you some things to think about.  Yes, you can certainly save a lot on development expenses. Then again, it can come back to bite you in rework expenses if there are communication issues.

How do you bridge the language barrier? (1) You need a go-to guy or gal who speaks the same language as your developers but will be working at your location. This is a must. Your probability for success is going to go way up by ensuring there is no breakdown in communications.

How do you receive the quality of code you need? (1) Use continuous integration (2) Use test scripts to understand requirements (3) Use short iterations (4) Have regular builds (5) Separate teams by functionality (not activity)

How do you communicate? (1) If you can afford to send/bring someone (an ambassador) over to work with the other team at the beginning of the project, do it. (2) It is critical that your "go-to" has a daily meeting with the team. Select a method that allows each side to see one another. (webcam/Skype) (3) Have everyone use Skype (VoIP) and/or a chat client for one-on-one communications. (4) Keep a Skype connection open between the offices. (5) Use wikis or other collaborative solutions for common project information. (6) Stay away from email, unless it is for formal communication. Information is going to get lost along the way and it will take longer to clarify.

Remember to use parallel communication methods, not serial.

Passion + Commitment + Skill = Success

I just read an intriguing post on Dan Schawbel's blog.  It was titled The Excellence Equation: Passion and Commitment. For several years, I’ve been promoting a similar “success” equation. The only component not listed in his blog post was skill. I think ANYTHING is possible if you have passion, commitment, and skill. If you’re short in one area, you can make up for it in another. I’ve worked with people that lacked a specific skill, but were so passionate and so committed, there was no way they were not going to succeed. When building teams for a project, I like to find individuals who excel in each area. I don’t want an overly-skilled team as much as I don’t want an overly-passionate team. But, when there is balance in all three areas, I’ve seen magic happen.

Free Project Charter Template

Project Charter Template

How many times have you started working on a project and don't even have formal authorization for that project to exist?  A project charter is a document issued by the project initiator or sponsor that formally authorizes the existence of the project, and provides the project manager with the authority to apply organizational resources to project activities.  Using this template will put all the cards on the table.  Knowing answers to key areas before you begin will save you time and money. This document includes areas for project overview, authority and milestones, organization, and points of contact.

On your current project, do you know the project oversight authority?  Do you know your critical success factors? Have you documented all of your project roles and responsibilities?  If you used this template, you would increase your chances for success by documenting the basics up front.

MS Word

[Click here to download the free Project Charter Template]

IE6 Friend or Foe?

Upon reviewing my Google Analytics account, I discovered 25% of my web traffic is from users using Internet Explorer 6. Almost the same amount of my AdSense revenue is from IE6 users. Being my site is designed for the current browsers, it misbehaves when viewed by IE6. I can't just ignore them, since clearly one quarter of my ad revenue is coming from these users. Still, I want to offer the best user experience. If you want to read more about the same issue impacting others, read the Mashable article. I'm seeing quite a bit of talk on Twitter about this issue. I wonder if it will have an impact.

Calculating Initial Velocity On Day Zero

While reviewing proposal documentation yesterday, I noticed the contractor's predicted velocity rate was pretty high.  Being they are not experienced in using Agile and they haven't even started the project, I was curious how they were able to calculate such a high velocity rate for the first iteration.  I know how many developers they intend to use and I know their proposed iteration durations.  I'm not going to get into the specifics as to how they estimated features (user stories, requirements, backlog items, etc.).  So, what did I expect? Velocity is a very simple method for accurately measuring the rate at which teams deliver business value. To calculate velocity, simply add up the estimates of the items successfully delivered in the last sprint or iteration.  What about the initial iteration?

Terms to understand when calculating initial velocity:

1. Number of Developers – How many developers will you have doing actual work?
2. Capacity - What is the maximum amount of work one person can accomplish in an ideal situation during the iteration?
3. Number of Iteration Days – How many work days are in the iteration?
4. Load (Capacity) Factor - The ratio of the actual work output over a period of time and the output if the developer had operated at full capacity over that time period.  e.g. 1/3 = 2.66 Hours , 1/2 = 4 Hours, 1/1 = 8 Hours
5. Velocity - How much Product Backlog value a team can deliver in one iteration.

Because you don’t know team velocity for the first iteration, plan initial velocity at one-third of total capacity in order to account for coffee breaks, design, email, meetings, rework, research, etc.  As an example, with seven (7) developers and at one-third (1/3) capacity, a total of 18.62 development hours are available per day.  Multiply the number by the number of work days in the sprint to arrive at the total of initial work hours.  These work hours will be applied against your estimated items, to arrive at an initial velocity.

(7 [Developers] * 1/3 [Load Capacity Factor]) * 21 [Work Days] = 44.1 [Ideal Work Days]

Ideally, the team should already be formed and stable, so that you can just forecast.  Unfortunately, this whole scenario is faulted. Not only are estimates for team capacity going to vary wildly, but what about the estimates for the deliverables themselves?  I can get pretty good at estimating a level of effort for work that could take a few days.  But the contractor that was noted in this post was estimating a 3-year project.  By the way, if you're curious, the contractor failed within 1 year. The federal agency then exercised their right to not renew their contract for the option years.  The agency then brought in a new contractor with more Agile experience.  

Critical Path is Back Up

As my eyes rolled to the back of my head last night, waiting for the server to finish configuring, I hoped my website transition plan was going to work.  Yesterday, I took control of the Critical Path hosting. That meant everything would have to be reinstalled on a new server and database restored. I kept asking myself if I had planned enough. Other then 6 hours of dead time, due to the release of the domain by the other host, things went relatively well.

The final indicator that I did indeed plan my transition correctly was when the database was restored this morning. The line read better then a tweet.

Import has been successfully finished, 1503 queries executed.

The Big Move

The Critical Path website is in the process of being moved today. If you get a timeout, it is hopefully just the IP address changing. This will be a true test to see if the backup and recovery procedures work. See you all on the other side.