Using eXtreme Emails! to Manage Projects

1. Write the Emails (Client Stories)

   The development team then write customer stories in priority order. We don't use cards as prescribed by some XP supporters. Instead, these are written as emails and all relevant parties (including people not on the development team) are copied on the email. This allows any person to comment on the story and request changes if the development team has missed something out or made an error.
   
   You can see more samples of client stories.

   
   Figure: Sample story email

2. Creating Release Folders

   
   Figure: An example of what your incidents folder should look like.
   The best practice to create and manage your incidents is to create a folder in your Public Folders and give it the product's name. Under this folder, organize your current and future releases into subfolders (Release01, Release02,...). Then place the related incidents (i.e. emails corresponding to separate tasks in the project) in the subfolders. Other folders that a project should have are:

   • _Management for all emails relating to project management and scheduling of the project
   • _Support for all emails from users who have a support question about the product.
   • _UnAllocated for all tasks/emails that have not yet been allocated to a release
   • _zsBackBurner for all tasks/emails that have been moved into a "future release" i.e. will be considered for implementation later on
   • _zsToLetCustomerKnowOnceReleased this folder lets you keep track of these users so you can email them when a new version is released.

   When you receive an email describing a bug or feature request, click the Incident button to make it an incident and move it to the corresponding project's release folder.
   

3. Place the Emails in the "_UnAllocated" Folder

   Place all the Client Stories you just created into the _UnAllocated folder you are now ready to place estimates on them and sort into your Releases. We prefix this with an underscore so that it appears first in the list.

   As you receive bugs and new suggestions place them into the appropriate release folder or if unsure into this _UnAllocated folder. However always keep this folder at zero before doing development work.

4. Place the Emails in the "_Management" Folder

   Place all the administrative emails (e.g. Release Plans, Sign Offs and Approvals on Work) in this folder. This allows you to keep a history of communication relating to the project.

5. Place the Emails in the "_Support" Folder

   Support emails should be placed in this folder. Support emails include queries about the product, support emails to users regarding the product.

6. Place the Emails in the "Saved Items" Folder

   Place all the correspondence emails related to this Release in the "Saved Items" Folder.

   Example:

   • If there is an item like Here is the approval for this release it would go under SQLAuditor\Release04\Saved Items
   • If there is an item like Here is the user name and password it would go under SQLAuditor\Saved Items

7. Place the Emails in the zsBackBurner Folder

   Place all the items that are deemed not important not be implemented in this folder.

8. Place the Emails in the zsToLetCustomerKnowOnceReleased Folder

   Place one email of each person who in _Support folder in this folder.

9. Estimate Incident Times and Allocate Incidents to Releases

   The developers should break the stories into tasks for the first Release. Using SSW eXtreme Emails!, assign estimates for the work involved and allocate the tasks to particular developers. These estimates are just rough guesses but give an indication of the developers initial impressions for the work involved.
   
   Once a period of between 1 - 3 weeks of work has been created, remaining items are pushed into a later Release. Sometimes during investigation the items are completed if it is prudent to do so.
   
   
   Figure: Only one field is compulsory to create an incident

10. Click "Apply View" to show Estimates & Custom Columns in Outlook

    

    
    Figure: Click "Apply View" on SSW eXtreme Emails toolbar to apply custom columns in the view.

11. Create your first Release Plan and send an appointment

    The development team can create a release plan using the "Release Summary" report from SSW eXtreme Emails!. This creates a report on all items in a folder, including their individual priorities and estimates. At this stage the client can determine whether they wish development for this Release to proceed. Remember anyone from the development team can view the release plan by accessing the Exchange Public Folder from the Internet.

    You should then arrange an appointment (subject "Debrief: Project Name") for the boss to come in and do a review in 2 weeks. This doesn't set unrealistic schedules, but puts pressure on the developer to have something done by then.

    

    
    
    Figure: Creating the release plan is as easy as clicking a button!
    

    Question: How do you structure email subjects for SSW eXtreme Emails?

    Answer: Incident Type - Product Name - Module Name - Description of Incident  Examples of an "Incident Type" would be BUG CODE CLEAN SETUP UI REPORT An example of a good email subject would be CODE CLEAN - SSW eXtreme Emails! - frmStatus - Remove Legacy "Upgrade Code" region Learn more about good email subjects

    
    Figure: It is easy to check the progress of a release using the public folder.

    See How to generate Release Plan using the SSW Agile Template for coding tester?

12. Additional items

    eXtreme Emails allows items to be marked as "additional items". Any additional item requests should be triaged according to priority. When the additional items are approved send the Revised Estimate report email

    

    Figure: Triage, mark clearly and get approval for additional items

13. Develop and Reply "Done"

    Complete development of each item in the release, and reply done. eXtreme Emails! will allow you to enter the actual time taken on the Incident.
    
    
    Figure: Enter a value for the Actual Time and change the status to "Completed". Then click on Complete button.
    When you complete the incident, the original email will be automatically moved into a subfolder called zsCompleted, e.g. CodeAuditor\Release14\zsCompleted.
    
    
    Figure: When an item is completed, the developer simply replies done.

    Question: If the client requests a new Release to be started ASAP, and to delay (or even cancel) the current release, how should I handle this in SSW eXtreme Emails!?

    Answer: We recommend that you: perform a debrief on the current release (then send it to your client) create a new release folder of same name + "(2nd)", then move the remaining (incomplete) Incidents to a new Release Folder get debrief and release plans signed Example: Say the current "Release 10 - Credit Card Import" is moved to a later priority, and "Release 11 - Push Payments" is to be released ASAP perform a debrief on "Release 10..." create a new folder "Release 12 - Credit Card Import (2nd)", then move all remaining incidents from "Release 10..." to the new "Release 12 - Credit Card Import (2nd)" folder get debrief and release plans signed

    Note: If the task you have done is a client issue or bug, then you need to put your done email (like: http://www.ssw.com.au/ssw/Standards/Rules/RulestoSuccessfulProjects.aspx#KB) into a subfolder, eg CodeAuditor\Release14\zsToLetCustomerKnowOnceReleased. And follow: http://www.ssw.com.au/ssw/extremeemails/ManageProjects.aspx#CleanUpClientNotifyFolder when you release a new version.

14. Send a Status Update every 2 weeks

    Every 2 weeks the developer has a meeting with the client to discuss status of project. If you can't have a meeting, a phone call is fine. If the release is finished then it will be a release debrief; if not it will be a status update. Some clients will also request that you send an update in Microsoft Excel with an update of the financials for the current release. You can use the following formula in Excel to convert the output (e.g. 1:30) to a decimal figure (e.g. 1.5).

    For field A1, this formula would be:

    =(HOUR(A1)*60+MINUTE(A1))/60)

15. Send the "Test Please" Email

    Use eXtreme Emails reports to send the Test Please email, while following standard testing procedures.

    Return emails should be triaged and flagged as Additional Items.

    

    Figure: Generate a Test Please Report

    You should use SSW eXtreme Emails to reply DONE or Failed to test pleases. Below is an example of how to reply to a failed test.

    

    Figure: Reply "passed" to a test please

    

    Figure: Sample "Test Please" email

16. Send the "Release Debrief" after Testing

    At the conclusion of the internal and external "test please", but before deployment, you should meet with the client to discuss the release. More

    

    Figure: Generating a Debrief Report

    

    Figure: Test cases metric

17. Rename the Release Folder to "zs"

    Once the debrief with the manager and client is deemed completed, the release folder is zs'ed. This is to ensure that new incidents are not posted in this folder but in the future releases.

    
    Figure: The zsCompleted folder.




18. Send the 'Install Please' email

The release is now ready for deployment. Hopefully there won't be any critical issues, but the important thing is to be ready so that if something goes wrong you can fix it quickly and make a new release. You should send an email to the client with the subject line 'Install Please'.

Dear XXX, The latest version of XXX_ProductName XXX_Version has been uploaded to XXX_LocalURL This version has also been tested by XXX_EmpName. Please install and test. Once tested and deemed OK by you, this should be installed on the necessary machines. To report any bugs or enhancement requests please follow the standard at SSW BugReport program Changes: XXX YYY If you have any questions please email me (one request/bug per email). The project plan has also been updated at https://mail.ssw.com.au/Public/Clients/     Your User Name is: XXX     Your Password is: XXX

Figure: Sample 'Install Please' email.

 

19. Clean out zsToLetCustomerKnowOnceReleased folder

You need to make sure all clients who are waiting for this version are notified, clean up your zsToLetCustomerKnowOnceReleased folder and reply to each of the email, like: http://www.ssw.com.au/ssw/Standards/Rules/RulestoSuccessfulProjects.aspx#KB

20. Proceed to step 1 for the next release

Note: As part of this, you should be moving unallocated items into the new release folder

Links

• 9 Steps to get your project up and running