Category Archives: Project Management

IT Budget Blog Series: Integration of Currency Exchange Rates

As part of the continuing IT Budget Blog Series, we look at how to integrate currency exchange rates.  This is especially important for two points of consideration when creating an IT Budget for international companies:

  1. Acquired Software/Hardware may not all originate where the corporate headquarters reside. This means a collection of budget line items could have more than one currency. To define a solid budget, all budget items need to be standardized to a single currency.
  2. The budget may need to be reviewed/approved by individuals worldwide. To provide a familiar denomination, you need the ability to convert all figures to a preferred currency with accuracy and ease.

This article helps discuss how to insert data from an external source (the web) into your Excel file and how often the data should be refreshed (i.e. never). Steps in this article are in reference to Excel 2016 (Version 1711) on Windows.

Continue reading


Free access to popular project management and document management tools

Today I received a pleasant surprise. Atlassian now provides their popular project management and document management tools for free*!

* Ok ok, free is a very lose term. Up to 5 active users, but still what a great offer!

Continue reading

When Affected Version and Fixed Version says “None”, short guide to Versions in JIRA

Today a coworker approached me what some might think is simple question, but others may not truly know… Where does the Fixed Version/Affected Version values come from? You see, in JIRA, by default in any JIRA deployment, is 2 attributes called Fixed Version and Affected Version as shown below.

Issuewith NoVersion

Before we jump into how to create values for these attributes, lets have a short discussion on WHY you want them. Versions provides a several benefits:

  1. Provides another method to organize (group) issues in your JIRA project, in conjunction with Components and Labels.
  2. Identifies key milestones in your projects.
  3. Gives each ticket a time reference based on business cases.

Who would use Versions, of course the obvious is Software Development teams, related to a point in time when a scheduled release occurs, usually resulting in clear scope for QC (QA depending on your team’s term), Marketing team for promoting the delivery, and release notes for end users, to list a few. But it is not only for Software Development teams, it can also be used for:

  • Office Managers can use it to identify schedules for ordering supplies.
  • Management Teams can use Versions to identify which topics to discuss in scheduled meetings.
  • Versions can also identify enrollment periods for school Admissions.

Anything that relates to milestones can be grouped using Versions, and what is great is that Versions are not limited to the traditional method of a series of numbers and periods (i.e. 1.10.123), they can be text as well.

So now the question is HOW to create versions. I am a believer in why reinvent a wheel (unless you are keeping it from going flat when you hit that pot hole, ouch). Atlassian documentation already provides a great article on how to manage versions. Do note that you need to be a member of the Administrators role in order to manage (CUD, Create, Update and Delete) versions.

If you are a proud user of JIRA Agile, you might also like to know that you can create and update versions directly from the Agile interface as described here. NOTE: Although you can create a version and modify version details such as name, description and Start Date/Release date from Agile, you are not able to modify the order or delete the Version from this view, instead go to the Administration view of the associated JIRA project.

Have fun playing with versions!

Bring Calm to Chaos, a success story with Atlassian Tools (How we estimated)

As we close this series of blogs (see links at bottom of the article for the entire series), we discuss how we estimated for the project, both in theory and using JIRA. As you remember, we opened the series discussing the type of project we were working with; a fortune 100’s ecommerce site. Like many ecommerce sites (or is it E-Commerce, or eCommerce, or…. what’s in a name anyway :-P), to stay competitive, priorities, promotions, pricing, products, pretty much everything, shifts continually. As a result, we ran the project in a modified Scrum in 1 week sprints. Crazy, I know, but trust me, that was not even flexible enough as it is, but alas we survived with 1 week sprints. In the next blog of the series, we discussed the theory behind the solution, identifying the timeline as follows:

  • Wednesday: Begin new sprint.
  • Thursday, 1PM: Requirements finalized by BA for next sprint.
  • Friday, 12PM: Estimation established by PM with TL assist
  • Friday Afternoon: Meeting of PGMs and PMs to discuss scope of next sprint based on estimations. Realign as needed.
  • Friday EOD: Deliver plan to client for approval.
  • Monday 12PM: Approval from client.
  • Monday, 5PM: Close sprint, perform Retrospective with individual teams.

The prime objective of this project was to support the operations of a hybris Commerce implementation. As you may not know, hybris Commerce Suite is built on JAVA, this means that our key specialized resources were our JAVA team members. This gave us the ability to define the capacity of the operations team based on actual JAVA members, helping to significantly reduce overhead effort to manage the scope of work in each sprint. After the PM and TLs established estimates of the tasks in the upcoming sprint, the PGM and PMs met and compared the estimates provided for JAVA effort and compared it to he team capacity using the following formula:

  • Absolute JAVA capacity – 20% = Reserve for unplanned and priority shift (again, super crazy project)
  • Result of above – another 20% = Reserve for bug resolution and minor task requests, this is was our final total capacity for the sprint

So if we started with 4 JAVA team members, the final capacity for the sprint was 102 man hours per sprint.

  • 160 (absolute capacity) – 32 (reserve) – 26 (bug and minor tasks) = 102 hours

Again, above was the theory, some times we had to throw it out due to extremes in priority, but we aimed for this goal each week.

When it came to JIRA, and JIRA Agile specifically, estimations was an interesting task. As mentioned in the earlier blog about the theory behind the solution, we ran the project across multiple scrum boards, a planning, collective and specific silo team boards. Additionally, in the actual tasks, we utilized the Sub-Task feature for functional team breakdown (i.e. Content Checker, HTML, JAVA). In JIRA Agile, there is a summary view in Planning mode (now called Backlog) that displays estimates as shown below:


These estimates however, is ONLY based on the parent task. This means if we go to each Sub-Task and enter an estimate and leave the parent task blank, it will result in showing no value in the Scrum Board. In probably many other companies, this would be a big bummer as that means they would need to manually enter the final total estimate in parent task, but for our case this worked out well. If you remember, earlier I mentioned our team capacity is centered on JAVA specifically as our specialized resource, so as a result, we would enter the JAVA estimate only in parent task, but still populate appropriate estimates in the sub-tasks for individual functional teams.

And that concludes the series of how we brought Calm to Chaos, thanks to Atlassian Tools. Don’t worry though, this does not mean the end of my blogs on Atlassian tools in general. I still have lots to share and will post additional articles in the future. 🙂

Read more about the Atlassian Solution below:
Bring Calm to Chaos, a success story with Atlassian Tools

Bring Calm to Chaos, a success story with Atlassian Tools (creating an JIRA Agile Sprint Board)

In the last session of this multi-part series, we spoke about the theory of the solution which involved the creation of 4 separate Scrum Boards using Atlassian JIRA Agile. In this article we will discuss how to actually create the initial Scrum Boards.

Continue reading

Bring Calm to Chaos, a success story with Atlassian Tools (the theory behind the solution)

In our blog yesterday, Bring Calm to Chaos, a success story with Atlassian Tools (the introduction and power of Components), I introduced you to a large complex project that involved many developers and client stakeholders. I also spoke about how to create new components to help organize the tickets into logical groups based on our team silos:

  • Marketing and Production
  • Platform

In this article I will discuss the theory of what we built and in next blog walk through actual steps of building the solution.

Continue reading

Bring Calm to Chaos, a success story with Atlassian Tools (the introduction and power of Components)

This is a blog I have been meaning to write for some time now, but been slow (lazy) to get there, andAtlassian
such a great story too!!! OK, let me frame up a story. It all began over 1 and half years ago. My company acquired an amazing contract with a fortune 100 client looking to rebuild their ecommerce site based on hybris Commerce Platform, a mature and powerful ecommerce solution, leader in all accounts. (selfish plug: checkout my hybris blog, hybris Blank, as I dive deep into the features it provides, as a non-coder) The client’s team in the APAC region grew exponentially over the time period, resulting from just a handful of stakeholders to over 20 people. As our company was the sole provider of both site maintenance and development of new features, we grew as well and needed powerful tools and processes to help control flow of requests. In comes JIRA provided by Atlassian. This blog will be part of a mini-series how we developed a successful project management solution using JIRA. The following article provides a glimpse into the founding blocks of the project, and future articles will describe in detail how we built and ran the solution through JIRA.

Continue reading