Category Archives: Atlassian

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


How to hide table borders in Confluence, per page

So I had a recent challenge with page formatting Confluence v.5.9.X and wanted to share how I solved it.


In a Confluence page, I wanted to include multiple Panel Macros, each containing column and row formatted content but without the borders. The goal is to show team member profiles with Image on the left and supporting text content aligned right, example below.

Sample of Table without border


Confluence contains the concept of Sections, but you can not have sections withing a Panel Macro (or within any Macro at that, only macros within a section). Next obvious option is tables, but Confluence tables do not provide the ability to define styling of the table per page, only in the global Space configuration, which as a normal user, I do not have access to.

Table Options


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 sprints and the lessons learned)

Welcome to part 4 of my series brings us to the topic of how to create actual Sprints in the JIRA Sprint Boards we created in the previous blog. Before we start though, lets talk about some lessons learned when you have multiple Sprint Boards pointing to the same JIRA project. In our previous topic, we talked about how we created a different sprint board for separate groups or activities related to our JIRA project. Although they are meant to help make the team smaller and more nimble, we are still one big, happy family, and no matter where you are, you still impact each other. That is also true in JIRA.

Continue reading

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