SSW eXtreme Emails! can be an effective tool for managing projects. It is especially
useful for software projects developed using the eXtreme Programming Development
Method (XPDM). eXtreme Emails! builds on
the fundamental XP principles of communications and simplicity. It maximizes the
benefits of email as a means of concisely informing clients of Tasks, Estimates
and Release Plans. It also enables swift decision making and clear communication
between the developer and the client.
Reporting is simple, without having to use larger applications for project management
such as Microsoft Project.
-
Determine the Priorities
The development team (consisting of clients, software developers, architects and
business analysts) should sit down together with a computer and a projector. They
should examine the current system in detail, and come up with a word document containing
all the ways to improve the application.
You can see a sample list of priorities.
Figure: Sit down with a projector and brainstorm the application
-
Write the Emails (Client Stories)
The development team then write customer stories in priority order. We don't use
cards as prescribed by some XPDM 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
-
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.
-
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.
-
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.
-
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.
-
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
-
Place the Emails in the zsBackBurner Folder
Place all the items that are deemed not important not be implemented in this folder.
-
Place the Emails in the zsToLetCustomerKnowOnceReleased Folder
Place one email of each person who in _Support folder in this folder.
-
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
-
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.
-
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.
Once this Release Plan is signed and approved, it should be set in stone.
You should only ever add new items to a current release when they relate to
a critical or "showstopper" bug. Critical bugs added
after a release plan is created should be marked as additional items
through eXtreme Emails!. If you reply "Done" to a task and the client replies back
with further changes, create a new item and mark it as additional in the current
release (as it is not a new feature).
Feature requests, user interface changes and non-critical bugs should be placed
in the "Unallocated" folder, not the current release. For example, if
the application crashes on open, it should be put in the current release as an additional
item. If a user wants the tabs swapped around so it would look nicer, then this
should be put into the "Unallocated" folder. Items should be moved
from the Unallocated folder when creating a new Release Plan.
Note: If a client requests that a new feature or non-critical
bug be moved into the current release after you have already started it, then find
out how important it is to them. As long as they fully understand that the release
will take longer than estimated, and the item is very important to them - then this
is OK. Make sure that you send a confirmation email to the client stating the nature
of the change to the Release Plan. Add the Incident as an additional item.
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.
-
Are you flexible with your releases?
Every now and then your clients are going to want to move on to another release
which they see is more important than the current one. Provided that it doesn't
have any negative effects on the current release, there shouldn't be any reason
why you can't stick to the "customer is always right" philosophy. So what
should you do when this happens?
- Move any left over work/items to the next release
- Send a debrief to the client with a note eg. As per your request we have just cancelled
Release five and will start on Release six. The remaining items have been moved
into Release seven.
- Send a Release Plan for the new release
|
We have a program called SSW eXtreme Emails! that
allows us to manage releases and track our project's progress with a built in estimating
and reporting tool.
|
-
You will typically receive emails and bug reports from the client during the release.
You should not work on any extra features except what is in the release plan. Move
only important emails (bugs, urgent requests or small items) into the current release.
Otherwise, the following issues occur:
- Estimates will blow out
- The release plan will be inaccurate
- The release plan will contain too many "Additional Items"
- The release will be delayed. This is particularly important for projects with strict
deadlines
Generally try to defer additional requests to a later release. Specifically, the
exceptions are:
- Known or critical bugs, they should be considered as part of the current release.
Developers should always be doing their best to eliminate bugs.
- Anything that is requested by the client with "Must be in this release"
- Any small thing (small is less than 30 minutes) that the developer has judged to
be easy to do (like fixing a typo, re-organize the GUI, etc). The developer must
be confident to get done within a very short period of time (less than 30mins) and
the developer should not add items to the current release for tasks that may take
too much time
-
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.
-
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) |
-
Send the "Test Please" Email
The release is then deployed to be tested. You should send
an email to your testers with the subject line 'Test Please'. The testers will offer
suggestions and feedback, allowing the application to be improved at this stage.
These return emails should be created as Incidents as additional items by checking
on the "Additional Items" checkbox.
Figure: Generating a TestPlease Report.
When replying to a test please, you should follow these guidelines:
If you don't reply properly to a 'test please', you might be wasting your time,
and some other tester's time.
So, how do you reply properly to a 'test please'? Make sure that you:
- Confirm you are a tester
If the developer did not name you, make sure he correct himself and resends the
'test please' email.
- Test within the hour
Testing is typically urgent. Make sure you know how urgent your testing is, and
test within the hour, if possible.
- Know what to test
i.e. Are you testing the reporting module, the time sheet module, or the whole application?
Usually, the tester should specify the modules to test in the 'test please' email.
Test the whole application by default.
- Classify issues correctly
Is it a bug or feature? The developer must fix it in the current release if it is
a bug.If it is a feature request or suggestion, add it to
a future release - do not stop a build of the current release for a feature request.
- Reply to all for each bug or feature
Make sure your replies follow the
Report Bug/Enhancement standard
This makes sure that no issue is reported twice, wasting developer and tester time.
- Specify how you received that bug
Through clear steps and screenshots, show the developer what you did to receive
that error.
i.e. What did you click on? What was running at the same time? Special environment
restrictions?, etc
- Reply 'done' to 'test please' email
The developer should not make a build untill you have reported all your bugs.
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: This is how to reply passed to a test please.
All bugs should be reported. There are 2 types:
- Normal ones These will be done in the next release
- Critical ones they stop a person from working eg. save a customer record crashes
under a normal circumstance. If it is one of these then include in the subject CRITICAL
and mark as important. It will be done in this release.
At the end send an email:
- "Testing Complete - OK"
- "Release Plan signed off
- "Days Taken: XX days
- "Mark: X/10
Figure: Sample 'Test Please' email.
-
Send the "Release Debrief" after Testing
You should sit down with the customer and discuss the release. It is a good idea
to do this before deployment, so that any problems can be resolved. A progress report
email entitled "Release Debrief" is issued, enabling the development team
to see how actual times compare with initial estimates, and check how many tasks
have been completed.
Figure: Generating a Debrief Report
You should also monitor the metrics of the project.
Figure: One metric is measuring number of test cases in a chart like this.
Also ask the client and your project manager for a mark out of 10
for how well the release went, and how happy they are overall with the work.
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.
-
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.
-
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 FirstName,
The latest version of ProductName ProductVersion has been uploaded to
LocalProductURL
This version has also been tested by 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:
If you have any questions please email me (one request/bug per email).
The project plan has also been updated at http://mail.ssw.com.au/Public/Clients/
Your User Name is: TimePRO
Your Password is: timepro
|
Figure: Sample 'Install Please' email.
-
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
-
Proceed to step 1 for the next release
Note: As part of this, you should be moving unallocated
items into the new release folder