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