Certified Scrum Master

I have successfully completed the Scrum Master Accredited Certification Program from the International SCRUM Institute:


Replacement Windows Project ROI

Last March, we upgraded our house with energy efficient triple pane windows and patio doors.  Although we expected the project to lower our energy consumption, the cost reduction was only part of the motivation.  We installed the new windows and doors to provide additional comfort and security for the family, while enhancing the house’s exterior appeal and resell value.  Since it was a substantial investment ($12k), I decided to spend some time verifying the project benefits.

When determining the return on investment (ROI) for any project, it’s important to consider both the quantitative and the qualitative benefits.  In other words, do not expect a speedy recovery of the full investment amount from the energy cost reduction alone; although that’s where I will start with my analysis.  To determine the reduction in energy consumption and to project the annualized cost savings, I decided to compare the PG&E bill for the past year (Apr 2009 – Mar 2010) against the same period 2 years ago.  Since California’s weather is pretty mild in the Summer, we do not have an air conditioner.  I was expecting the savings largely from the Winter months when the furnace is running, so I was surprised to find a consist trend of reduced energy consumption through out the year.

The chart to the right shows the monthly PG&E bill (in blue) and the year-over-year delta (in green) for the same month.  While there are some anomalies that I attribute to weather and other causes, the cumulative effect is that we saved on the average 25 to 30% per month for a total of $750 this past year.  When I project the savings over the next 10 years factoring in rising energy price (conservatively 5% increase a year), the total saving amounts to approximately $9,500.  Since the project also qualified for an one-time $1,500 federal tax credit for energy-efficient home upgrades, I expect we will reach the break-even point in about 12 years or less.

I love my new new windows and patio doors, and I would gladly pay the full value of the project for the enhanced feeling of comfort and safety alone.  They truly enhance the house’s exterior appeal and add to the architectural detail that was missing from the old, aluminum windows.  From within the house, it feels much more insulated and secure too.  The new windows significantly dampen exterior noise while the double latches provide extra protection from unwanted intrusion.  Fortunately, a typical windows replacement project like this one can increase the value of the house by as much as 56% of the project cost, according to the experts at HGTV.com.

Back to the ROI calculation, if I consider that approximately $6,700 (56% of the project cost) is recouped in the form of increased resell value and that I benefit from an one-time $1,500 federal tax credit, then $3,800 is really what I paid for the qualitative benefits.  It is also the true cost that I will need to recover from the energy savings.  Based on my assumption of $750 savings annually, with energy cost rising, I can expect to reach the break even point in 5 years.  All savings beyond year 5 are the icing on the cake.  That’s a darn good return on investment (ROI), one that makes me quite happy that we went ahead with the project last year.

The following table shows calculation for the final ROI:

To see the before and after pictures, check out my Picasa Web Album.

Original post on https://chenalfredc.wordpress.com/

Learnings from the Advanced Download Widget

Recently, we released a new feature to the download platform that powers the Sun Download Center.  Internally, we refer to it as the Advanced Download Widget (ADW).  Essentially, it’s a Web component that can be deployed on any Sun-branded Website, to deliver an integrated and streamlined download experience.  Working with Lifecycle Marketing, we have also integrated the ability to present the user with a free offer (e.g. whitepapers, training, etc.) that complements the download.  It’s completely optional, but to receive the free offer, the user will need to login with a Sun Online Account or create a new one.  To see it in action, checkout the Java ME SDK 3.0 download page.  Although the project was generally successful, there were some lessons learned (in terms of went well and what can be improved from my own personal perspective) that I would like to share via this blog for future reference.

When developing new Web functionality that relies heavily on Web browser technology, it’s important to understand your users.  Do they largely run on a single Web browser / platform combination (Intranet apps), or do they span the gamut in browsers and platforms used?  The answer may greatly affect your project plan and testing strategy, so find out before you start on your project.  Sites such as Wikipedia publish aggregated Web browser usage stats for the Internet, but it is better to take your own measurements if possible.  Our sampling of a very popular Java download yielded slightly different distribution with 48.6% running Internet Explorer and 40.8% running Firefox.  The data helped shape our testing strategy.

Given the constant evolution of the Web browsers, it’s not always practical to maintain backward compatibility to outdated Web browsers; however, forward compatibility for new releases should definitely be a priority.  Internally, you want to establish guidelines on the Web browser makes and versions, as well as the browser platforms that you can support.  This way, you can provide Engineering and QA with clear expectations on the testing scope and staffing needs.   It’s also good to have designated personnel who keep tracks of the product roadmap for key Web browsers.  During the development phase for the ADW, new version of Firefox (3.5) and Safari (4.0) were released, but they were not on our radar.  We later uncovered some minor incompatibilities with these Web browsers during the testing phase that prompted additional round of testing and contributed to some avoidable schedule delays.

One key aspect of project management is accurate planning of the time and resource it takes to complete the project.  While the Development and QA phase are largely determined by Engineering’s estimates, the business generally drives User Acceptance Testing (UAT) and therefore estimate the resources and duration required for UAT.  Because the project scope varies from release to release, successful UAT planning requires a good blend of gut feel (art) and common sense (science).  By applying past experience and intimate knowledge of the system to the bug fixes and enhancements in scope, you can devise a rough approach to the UAT test plan and test cases.  From the estimated time for completing each test case and the availability of UAT testers, you can then derive the duration required to complete 1 round of user testing.  When testing new features that relies heavily on Web browser technology, be sure to add extra time and/or testers for targeted cross browser/platform testing.  Finally, allow time for bug fixes and at least a second round of user testing to make UAT a success.

Finally, while the project life cycle ends when the release goes live, the product life cycle continues on.  By product, I’m referring to the system or the download platform in this case.  Although it’s possible to roll out new features that meet the user’s needs on day 1, quite often the road to nirvana involve a couple design iterations.  To avoid the design-in-a-vacuum pitfalls, it’s essential that you have ways to collect feedback and gain insights into the user’s real world interactions with your system.  In our case, we chose to conduct a usability study to gather feedback from a diverse group of users whose experience with Sun ranges from none to developers and Sun customers who are quite familiar with our Websites.  Although the usability study was insightful, we plan to integrate Omniture into future releases so we can measure and assess the usability of the ADW across the entire user base.  Meanwhile, we have other ways (see my blog on The Voice of the Customer) to collect and act on customer feedback as well.

Stay on the “Happy Path”

Do you use Google to search the Web?  Isn’t it great that Google returns a search result of relevant information for just about anything that you enter.  In software engineering, there’s a term that describes such predictable and reliable outcome.  It’s call the “happy path” and it defines the default user experience when the software works as intended.  I first learned about it in college.  It has been a while, but I think the
subject still has a lot of relevance today, especially in Web application design.

Imagine your reaction if Google errors out or returns no search results, every other time you use it.  That would not be a good user experience.  So how do you factor in the happy path into the design and the implementation plan for your application?  Whether you are building a Social Media Website or an IT application for internal consumption, the process starts with good product or business requirements.  When you write the high level requirements and use cases, you are defining the happy path.  Good requirements should specify how the application process the end user’s request to deliver a user experience that meets or exceeds the end user’s expectations; focuses on the desired functionality.  In the case of Google Search, I’m guessing that the original requirements may have been written as follows:

Build a search engine with a simple user interface that accepts the user’s input, intelligently determine the most relevant Web resources, and present the user with the search results sorted by popularity.

Good requirements also facilitate great design.  When evaluating your design options, you should focus on a design that engages the user and keeps the user on the happy path.  Some Web applications calls for rich interactions (RIA).  In the case of Google Search, as simple design seems to work very well too.  Either way, a streamlined user experience will definitely appeal to the users and enhance conversion rates.  Your design should also account for how the application recover when something goes wrong.  There’s a popular saying “Sh*t happens“, and it definitely applies to anything on the Web.  Most users will tolerate some mishaps,  but you really should do your best to minimize the impact to the user experience.  Your average Joes won’t put up with HTTP 404 or 503 errors, but they will appreciate good humor such as the case with the Twitter Fail Whale.

Finally, how do you ensure that you are on target with your design?  It is important to test out the new functionality and verify the outcome against the original requirements.  In-house User Acceptance Testing (UAT) is a common practice for IT applications, and external Web applications without established communities.  Since UAT involves a controlled group of testers (generally superusers), be sure to provide all users with a feedback loop.  Public beta testing and user-driven designs seem to be very popular among Web 2.0 applications.  GMail which was launched in 2004 has retained its beta status despite its success and mass adoption.  Facebook with over 200 Million users engages the user community through the Facebook Blog.  Both are tremendously successful in attracting and retaining users.  Although there’s not a singular approach to engineering great solutions, there’s definitely one common theme:  Stay on the happy path.  After all, who doesn’t appreciate software that simply works.

My April Fools Day

Yesterday, I experienced April Fools Day in all its glory.  Like the day before, I was taking CalTrain to San Francisco to attend the Web 2.0 Expo.  It was only the 2nd day of the conference, but I felt I was starting to develop a commuter’s routine.  Unlike the day before, I decided to park at the nearby free parking lot which required an extra 3 minutes walk to the Sunnyvale CalTrain station.  Unfortunately, I didn’t pad my travel time.  By the time I arrived at the train station, the 7:13am express train had arrived.  I tried to rush thru the ticket purchase process, hoping still to jump on that train.  As I completed the electronic ticket purchasing process, The train doors had closed.

So I missed the 7:13am train, but luckily the next train arrived at 7:18am.  I jumped aboard thinking I will still arrive in San Francisco by 8:20am in time for the first conference session that starts at 8:30am.  As the train pulled away, I inspected my ticket and realized that I haven’t purchased enough fare.  The CalTrain fares are based on zones.  To travel from Sunnyvale to San Francisco and back, I needed to purchase a round trip ticket from Zone 3 to Zone 1.  In my rush to make the 7:13am train, I had purchased a round trip ticket from Zone 3 to Zone 3; not so smart without my morning Starbucks.

I decided to jump off the train at the Mountain View station to purchase additional ticket fare, since you cannot purchase tickets onboard (VOC to CalTrain:  How about placing a ticket machine aboard the train for people who forget to buy the ticket at the station)  Of course the ticket machine wasn’t nearby, so I needed to run to the machine and rush thru the ticket purchase process again.  This time, I managed to purchase the correct ticket fare.  Except as I turn around, the doors on the train had closed.

By now, I was starting to realize that this was no ordinary day and that somebody (perhaps myself) was pulling an April Fools joke on me.  The next train (at 7:37am) a local commuter train would take me to San Francisco by 8:48am, so I opted to wait for the 7:57am express train that eventually got me to San Francisco by 8:42am.  For 1/2 hour, I waited at the Mountain View station, enjoying the fresh morning air and the free WiFi courtesy of Google.  It also provided me with the time to pause and reflect on the experience.

So why didn’t I give myself more time yesterday?  This morning, I was determined to not repeat yesterday’s mistakes so I left the house 5 minutes earlier.  By the time I arrived at the station and purchased my ticket, there was still 1 minute to spare.  Through iteration, I think I have finally perfected my commuter’s routine.  Unfortunately, the Web 2.0 Expo ends tomorrow.  As I wrap up on this blog entry (aboard the CalTrain ride this morning), I believe there’s a lot of lessons to be learned from sharing this experience.  Of course, I hope you enjoyed my April Fool’s Day story as well.