NB: It would be great if TFS Web Access had functionality to add standard items to a Release (aka iteration)

How to create a Release Plan

Figure: Use SharePoint Document Library Template for creating consistent ballpark Figure: Read the instructions about how to use this template

Figure: Use Menu Calculator to understand the common estimates

Figure: Use Resources sheet to assign resources

Figure: Use the Release sheet to enter all the work items and calculate ballpark
Finally, you should copy and paste this Release sheet into an email and send to your client. Before that, make sure you talk your client through it first.

Figure: Send the ballpark by Email     

Winning the Project- Publish these Work Items to TFS

1.  Open Visual Studio
2.  Create a new Project in Team Explorer

    3.  Define new Iterations

Figure: Accessing the Areas and Iterations menu from your project in Team Explorer
Figure: Add appropriate named iterations

              4. In SharePoint, open your Release Summary
         5. Create a new Worksheet in the same Workbook for your release plan. Rename  it to "TFS Work Items"
         6. From the "Team" ribbon tab, click "New List"
         7. Select the Team Project you Created


         8. Click "Input List". This will connect Excel to TFS, and allow you to enter Work Items to be published


    After you do this, it will generate a worksheet that looks like this:


    9. Click "Choose Columns", and make sure these columns are selected in the following order:
        a. ID (will be included automatically);
        b. Title
        c. Baseline Work
        d. Work  Item Type





    10. Copy the first four columns of the release summary onto a blank section of the TFS Work Items work sheet


    11. Delete the Resources and Hours per resource column

    12. Cut the Task and Man Hours column and paste it into the input list. You MUST use “Paste-Special”, and select Values, otherwise you will get an error.

    13. Set the "Work Item Type":
        a. Subheading/Categories are considered "Scenarios" in TFS
        b. Work Items are set as "Task"

    14. Click the "Publish" button from the ribbon.

Figure: Remember, a batter aims to hit the ball way out of the ballpark. Don't set an indefensible boundary too early

• An architectural roadmap recommending technical solutions
• Time allocated for further specification work to be included in each Release. At SSW we only create detailed specifications for 3 releases at a time
• A breakdown of the required software application into its core components, likely to include the approximate number of main features (e.g. screens, reports or sitemap)
• An integration plan
• A deployment strategy
• A 'future functionality' wish list - requiring the client to set the priorities for the project through defining what is in and out of scope
• A detailed list of 'issues' associated with the existing system which impact future development and maintenance
• Hardware and licensed software recommendations
• A sample mock-up screen where the project is less than one month

Sample Initial Release Plan

1. Release 1 (1.5 man months) - Database schema design
2. Release 2 (1.5 man months) - Development Module 1 Customers
3. Release 3 (1.5 man months) - Development Module 2 Products
4. Release 4 (1.5 man months) - Development Module 3 Orders
5. Release 5 (1.5 man months) - Development Module 4 Suppliers
6. Release 6 (1.5 man months) - Development Modules 5 Employees

With the Initial Release Plan, the client can see whether SSW understands their business and the requirements for their software development project. The ballpark estimate allows them to decide whether the project is feasible for their budget and time-frame.

SSW offers both fixed price and time and materials contracts although all specification work is done on a time and materials basis.

• Time & Materials: We work to your specification, billing for the number of hours we accrue. The benefit of this type of development is flexibility – you are able to add, remove and reprioritise development tasks during development.
• Prepaid Time & Materials: Time and Materials clients have the option of a prepaid discount – buying blocks of 40 hours per resource in advance entitles you to a $15 per hour discount on the hourly rate of each developer. You should see the specific terms on our Terms & Conditions.
• Fixed Price: Fixed price contracts necessitate having a specification signed off before work commences. This spec can't be altered, so additional items must wait until the fixed price contract is completed. The benefit of this type of development is that your expenditure is fixed. Fixed price projects are charged at a 20% premium to the project cost based on the standard hourly rates.

The following are items that are address in a architecture/code review:

Background information/overview of the project

• Current system
• Objectives of the system
• Number of users (internal, external, edit, read only)
• Current technologies
• Current environment (SOA, SOE)

Points for discussion

• Rich client
• Web client
• Smart client (any disconnected users?)
• Technology choices
  • Persistence layer (SQL Server, Access, SQL Express, LINQ, netTiers)
  • Business layer
  • UI
  • Communications
  • Workflow
  • Integration - external systems
• Requirements for 'package' software
  • PerformancePoint
  • Reporting Services
  • Accounting packages
  • SharePoint
• Data migrations
• Data reporting
• User experience
• Network
• Responsibilities/players
• Infrastructure
  • Network
  • Hardware
• Deployment
  • Staged implementation
  • In parallel
  • Development/Test/Staging/Production
• Disaster recovery
• Change control/source control
• Build Server
• Performance
• Scalability
• Extensibility
• Design patterns
• Maintainability
• Reliability (failover servers?)
• 'Sellability' i.e. is the solution appropriate for the client?

Enterprise Architect

• should have a datetime of the last time the diagram was modified so we have an indication of when it is out of date
• should have the ability to mark items as ‘todo’. E.g. it would be nice to have an indication of which items on the diagrams have been completed, and which are still pending

If you've run the Spec Review successfully the client should not be surprised by anything you present. This means discussions should focus on issues such as what particular requirements could be added into the scope in the first phase, or what releases can be completed by what date, rather than spending the meeting helping the client regain consciousness after they blacked out from seeing the price.

The Spec Review presentation should be scheduled by the Project Manager or Account Manager for the afternoon of the final day of the Spec Review. 

“I will send you a proposal when I get back to the office.”
Figure: Bad example – a common mistake is to tell the client you will complete it later

“Let’s schedule a meeting now for Wed 2pm. I will send a meeting invite to all the stakeholders.”
Figure: Good example – this is an appointment with specific time for the next schedule 

• You are striking while the iron is hot
•  All parties benefit while the information is fresh in their minds
•  The client wont experience the inevitable delays when you go back to the office and get stuck on other client issues that appear more urgent

• An email, or
• A Word doc, or
• A PPT presentation (recommended)

Once again, the presentation needs to pass a 'test please' from another senior employee before the meeting takes place.

Types of specifications

1. I have an idea…
   Run from this
   or
   verify they have a really hefty bank account!
2. High Level Requirements Document
   This will read like a wish list with no details and many unanswered questions
   Figure: High Level Requirements are very vague and open to many interpretations
3. Detailed Requirements Document
   
   The details have been fleshed out and allows developers to write Functional and Technical Specifications
   
   • We need a login page for www.northwind.com
   • Must match existing site look and feel
   • User name is already in the Users table in the ABC database (SQL Server 2008)
   • Password should be at least 8 characters
   • .NET 4 is already used for the existing site so that is what this should use of course
   • Should look like this:
     
   Figure: Detailed Requirements have more of the details you want
4. Functional Specification
   This will include detailed mock-ups for the UI, use cases/user stories and might be at a level to allow for fixed price quoting on the project
   • We need a login page for www.northwind.com
   • Must match existing site look and feel
   • Users table must be defined and added to the ABC database (SQL Server 2008)
   • User Name consists of user first initial and first 7 characters of last name
     - For example Joe Jones -> jjones
   • Password should be at least 8 characters
   • Site uses .NET 4 and this interface must be added to existing project
   • This is the layout for the login interface
   • A red asterisk (*) should be displayed if a value is left blank and Submit is pressed
     
   Figure: Functional Specifications go into more detail about the user interface and interactions in the system
5. Technical Specification
   This is the blueprint for the application. There should be no unanswered questions and should allow for a fixed price quote.
   • We need a login page for www.northwind.com
   • Must match existing site look and feel
   • Users table must be defined and added to the ABC database (SQL Server 2008)
   • User Name consists of user first initial and first 7 characters of last name
   • For example Joe Jones -> jjones
   • Password should be at least 8 characters
   • Site uses .NET 4 and this interface must be added to existing project
   • Define the data model explicitly
     
   • Must work with IE7, IE8, IE9 and FF3
   • Must display correctly at 1024x768 resolution
   • Must support ANSI characters for Username and Password
   • Will not support mobile browsers
   • Will not be tested with localization (assumes en-us local on US versions of software)
   • SQL Membership provider will be leveraged
   Figure: Technical Specifications will become the blueprint of the application. There shouldn’t be any unknowns.

Tip: Set this up on a daily schedule so the Scrum Team get this in their inbox each day.

Suggestion for Microsoft #1: Add a Summary Number in large font at the top, eg. 55% complete.

Suggestion for Microsoft #2: Add this great report to the Microsoft Scrum TFS Process Template.

Need to know $$$, read Do you get regular updates on costs and progress (aka Project Progress, Burndown, Story Overview)? to see which reports you need to get a complete project progress overview.

The answer varies from project to project and those with the responsibility to provide the answer are the architects on the project - subject to peer review. Having said that, our standard is to schedule specification time in every release, especially time to complete (and review) screen and report mock-ups.

Figure: Create the Ball Park

The term "release" implies the unit of work is delivered at its completion, but delivery can be either public (i.e. to the client) or private (i.e. just to the development/test environment). The more frequently we delivery releases publicly the better the application will be.

What do I need to include in a Release?

Releases contain two main types of work:

1. Work items relating to the particular release (e.g. Create Customers.aspx). We call these Project specific Work Items; and
2. Work relating to all releases (e.g. specifications, management, administration, testing, fixes, software audit etc.). We call these "Required Tasks".

Each type of work makes up (generally) 50% of the total project time, meaning each taking 12 days.

Each project has an agreement on the scope of the project; the project manager will break down this agreement to a task list. The task list and agreement is the baseline for the whole development process.

Whenever you receive an request from client, you must:
• Check if the task is in the scope of the agreement/task list before adding to TFS.
• Add the original requirements from the agreement/task list to task description before assigning to developer.
• Check if you can find the original task from agreement/task list.
  • If yes, work on this task to implement the original requirements.
  • If not, you should send a out of scope note to your project manager with the reason, and give the estimate for this extra work. An alternative is to send this note to your client directly, let them know that the work is out of scope and extra cost is required.
• For those tasks that you are not sure, send them to the project manager with your comments.

Make sure you don’t do any extra work out of the scope. Any extra work should be approved and paid.

Project Specific Work Items

• (e.g. Create Customers.aspx)
• 12 days

Required tasks

• Further specification (including screen and report mock-ups): 2 days
• Unit tests: 1 day
• Testing: 1 day
• Fixes from testing: 2 days
• Software Audit: half day
• Fixes from the Software Audit: half day
• Project Administration: 1 day
• Project Management: 2 days
• Unknowns: 1 day

Working together is important otherwise:

• Avoid Designer vs Developer
• Designers like it to be perfect, so their designs have the presentation intended
• If they are working they are more understanding and you avoid
  - e.g. It is not perfectly centred
  - e.g. This pixel is out of alignment
  - e.g. Colours are not right... this is 1 shade off due to compression

 Figure 1 - How designers work

Some activities are run internally; some are run with the client.

Thankfully Project Server 2010 allows us to stay on top of the project with live updates with TFS and the project gantt chart to track progress and delays.

From this initial meeting we will first need to conduct a specification review. This first step is $10K
- Requirements Workshop (2 x ½ days)
- Specification Review (example image)

We will scope out the next two releases.
Figure: Good example - work in small chunks of work with details about what you will do

Open conversations

Figure: Have a frank & open interview style meeting with a data projector to get everything out on the table

The Specification Review is conducted by two experienced developers at the client premises in close consultation with the client. The time allocated for a Spec Review is generally 1 - 5 days depending on initial expectations of the project. The rule of thumb is 1 - 2 days Spec Review per estimated month of project time. The purpose is to understand the whole project but, if the project is greater than six months, focus primarily on the first six months. The Spec Review is a process that will demonstrate to the client whether you have the commercial sense to understand their **business** and have the technical and management capacity to complete the project.

Talk Business Process

• User Story Workshops: Conduct workshops with different groups of users (e.g. management, back office, customer service) to build the "user stories" which the business wants. This ensures you get all users get their say. Some "nice-to-haves" might actually be quite easy to implement. User stories can then be prioritised and fleshed out.
• Review Documentation: Reviewing any documentation the client may already have. Remember clients are mostly looking to software consultants to assist them in solving business problems.
• Technology: Warning: Detailed discussions about technology with the client, unless they have a specific business purpose, are unlikely to be useful. For example most clients won't be interested in a discussion about whether to use MVC or ASP.NET traditional at this stage.

Do something valuable

Most experts at software consulting will be able to provide a small improvement to the current system 'on the fly' during the Spec Review. This may be something as simple as adding an index to a table and thereby increasing the performance of a webpage.

Use 'Corridor Conversations'

Figure: Use corridor conversations to prevent nasty surprises

While the information collected and the conclusions of the Spec Review are presented formally at the end of the Review it is important that the Project Manager convey key points to the client as they emerge through the course of the Review. The formal presentation is NOT the time to be presenting new information to the client. Formal meetings can have an Us vs Them feel. Addressing key potential sticking points of budget and technology informally during the course of the Spec Review relieves the potential for unwelcome surprises during the Spec Review presentation. Canvassing the issues beforehand in casual 'corridor conversations' clears the decks for an agreement, rather than increasing the risk of heated discussions if you surprise a client at a formal meeting. For example, ask the client "building the cube will add around two months development time, shall we leave this out of the current scope, or do you want it in?" Remember, no politician challenging for the leadership ever calls a vote before he or she knows the numbers; you too will avoid presenting a solution at a meeting if you aren't convinced the client is already agreeable. Through the course of the Spec Review the client will by aware of at least the following:

Budget ballpark indications expressed in terms of man months

Each man month for senior software consultants is generally tens of thousands of dollars. Squabbling over $500 here or there in the ballpark phase is a level of detail neither side can be confident of. Clients needs to be realistic about what they get for their money.

"Now that we've spent a few days speccing this out, we believe the solution will take approximately 6 months which is $204,000+GST"

Bad Example - Far too firm a price when you don't know any of the detail

"Now that we've spent a few days speccing this out, our projection is the project will take a minimum of 6 man months (around $200,000+GST) to complete but this may change depending on what is finally agreed in the Specification. The price will vary depending on resources used and the time that elapses over testing.

We propose to do a $10,000 spec review and firm up a price for the first 2 releases."

Good Example - leaves some wriggle room at these initial phases

Technology options

At this stage you want to consider the most relevant technologies. For example SSW will likely pursue recent Microsoft technologies. Some clients might want to do their own research or need some time to think about their options before agreeing to newer technologies.

Proposal

You should follow Rules to Better Proposals when documenting a Specification Review.

Test Please

The Project Manager must run a test please by other senior staff before anything is formally presented to the client.

1. Open MS Project and connect to your Team Project Figure: Click “Choose Team Project” and choose the project you want to track
2. Query the work items from the team project Figure: To select the work items that you want to use you should click on “Get Work Items” and choose a query.Note: normally you want to create queries for each of your Releases, then you can quickly import them together.
3. To Track progress, we will use the “Team System Task Sheet” view; this can be selected from the “View” menu.
4. Your work items will be imported and arranged within a hierarchy. As we are trying to track the progress, we want to keep “Original Estimate”, “Remaining Work” and “Completed Work” together, so drag them after the Work Item Title.Figure: Arrange your work items so we can easily track their progress
5. In order to have the cost calculated, we need to assign a rate to each of the resources. This can be done by going to “View | Resource Sheet”
   Figure: Assign resource rates
6. When you switch back to “Team System Task Sheet”, you will want to add the following fields so we can see the cost status;
     a.  Baseline Cost
     b. Remaining Cost
     c. Actual Cost
   You will notice the “Remaining Cost” column has been calculated based on the “Remaining Work” column and the Rate we entered for each task.
   Figure: Showing the cost columns
7. In order for MS Project to calculate and display a total cost for your current release you will need to add a summary task at the top level of the project tasks.
   Choose the 1st task in your project, right click and create a “New Task”
   Figure: Create a summary task at the top Name the task as per your release name so you know what this plan is for; also you don’t want this task to be created in your TFS as a work item because it’s just a summary, set “Publish and Refresh” as “No”.
   Figure: Don’t publish and refresh this summary task In order to make this a summary item you need to select all the other tasks and indent them. To achieve this click the little red forward arrow in the toolbar.
   Figure: Indent tasks Now, your summary task is ready and it’s showing the total cost for your current release: Figure: Total cost is calculated

Baseline management:
Baseline management is very important for every project manager as it helps you to determine the budget usage; once the client approves your initial estimate for the project it will become your baseline. So before you set a baseline in your MS Project, make sure the client approves it.

To set a baseline, choose “Tools, Tracking, Set Baseline” from the menu: Figure: Set Baseline …Figure: Choose “Baseline” and click ok

A handy feature of MS Project is its ability to handle multiple baselines. Use a new baseline to seek approval from clients when they alter the project scope.
Once your baseline is set, you will be able to see the “Baseline Cost” column is showing $,Figure: Baseline Cost is showing $

Track your project on the go
When your project is running, your developers will update the “Remaining Work” and “Completed Work” columns from TFS, they may not use MS Project so you will need to refresh your MS Project file to get these changes, and the $ will be calculated on the fly to give you up-to-date status.
To refresh your project file, simply click on the “Refresh” button in the toolbar. Figure: Click the “Refresh” button to update your project file.Figure: Budget usage is calculated. Note: If you find that the values are not calculating properly, it may be that the calculation mode is set incorrectly. If pressing F9 updates the values you should change the setting “Tools | Options | Calculation” from “Manual” to “Automatic”.
Figure: set the calculation mode to “Automatic”Also make sure “Actual costs are always calculated by Microsoft Office Project” is enabled.

All peers that worked together should evaluate each other by filling the Peer Evaluation Email every month.

The evaluation is done by ranking from top to bottom and giving constructive comments in “Start, Stop, Continue”
e.g. (Start...) checking in with better comments  
e.g. (Stop...) coding without a user story  
e.g. (Continue...) with your helpful SEO comments

Note: Comments must have an option to be anonymous.

If you do not rank a listed peer it means that you have constructive comments to give them but are not qualified to assess the person’s value
e.g. an admin person evaluating a technician and vice versa; or a work experience person new to the company who feels qualified to give comments only.

SharePoint and TFS allow collaboration from Developers, Project Managers and other stakeholders.

Quickly store important details:

• Server details (Dev, Test, Production)
• Usernames/Passwords for testing accounts
• Change logs
• Upcoming features

Documents

• Requirements/Specifications
• Mock-ups

Additional Information

• Server settings
• Username/Password