Tag Archives: Agile

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

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:

EstimationFlow

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