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.

The goal is to provide each smaller team their own view of tasks, without seeing unrelated topics. This helps both individual developers and the managers have a clear picture of what is asked of them. We also required a view for the client and PGM (Program Manager) to plan upcoming activities at a high level for future sprint planning. Luckily JIRA has a great product called JIRA Agile that fit perfectly into our needs.

JIRA Agile comes with 2 types of Sprint Boards:

  • Scrum
  • Kanban

My personal experience is on Scrum, and as such, the solution is based on Scrum Boards. Scrum Board provides management ability to create Sprints and backlogs for team planning and time management. What is great about JIRA Agile is it’s tie directly into JIRA projects, and even better, ability to have multiple Agile Scrum Boards for same project.

To support the project needs, I created 4… yup, you read that correctly, four separate scrum boards, each to meet a particular need as described below.

Collective Team Board

The Collective Team Board is the main Sprint Board to provide a clear view of all Tasks underway or planned in upcoming sprints within the project. This is the ONLY board that will have the actual sprints created (more on this topic in a future article) and have a simple filter applied:

  • Where Ticket Type = Task or Ticket Type = Sub-Task

Primary audience for this board is the shared resources in the team, including:

  • PGM (Program Manger)
  • HTML team
  • BA (Business Analyst) Team
  • QC (Quality Control) Team

Scope Planning Board

The Scope Planning Board is the key sprint board used for high-level planning for scope of deliveries. This board is used by the PGM to work with Client on establishing priorities and identifying strategic deliveries based on large topics instead of diving into detailed tasks. This is achieved by filtering the board:

  • Where Ticket TypeStory

The PGM will organize the tickets of type Story by performing one of the following:

  • Add story to existing sprint if specific date is specified (again Sprint is created ONLY in the Collective Team Board)
  • Order Stories top down within sprints or Backlog for order of priority

PGM will also apply to the Story:

  • Due Date if delivery date is identified by client
  • Component: If Story relates to Platform, Production or Marketing (should only select one).

The Scope Planning Board is NOT a promise to client for timeline of deliveries, ONLY used to establish priorities and provide a glance of potential timeline of key requests. The client should have full access to this board and be able to align priorities as they shift. Actual Estimations will be discussed in a future article.

Platform Team Board

The Platform Team Board is used by the Platform Team to manage their tasks. Unlike the Collective Team Board, this board will have a filter as follows:

  • Where Component = “* – Platform” and  (Ticket Type = Task or Ticket Type = Sub-Task or Ticket Type = Story)

This will limit the scope of items shown to only those related to Platform Team. This board is managed by the PM of the Platform team and works with TL and BAs to breakdown the stories into tasks and sub-tasks and establish estimations (to be discussed in future article).

Production & Marketing Team Board

The Production and Marketing Team Board is used by the Production and Marketing Team to manage their tasks. Unlike the Collective Team Board, this board will have a filter as follows:

  • Where Component = “* – Marketing” or “* – Production” and  (Ticket Type = Task or Ticket Type = Sub-Task or Ticket Type = Story)

This will limit the scope of items shown to only those related to Marketing & Production Team.This board is managed by the PM of the Production & Marketing team and works with TL and BAs to breakdown the stories into tasks and sub-tasks and establish estimations (to be discussed in future article).

Flow of Work

Due to the nature of the work, we worked on a 1 week sprint. Crazy, I know, but due to a competitive market in online retail, requirements and priority alignments changed constantly and our client demanded a lot of flexibility. A such we performed as follows:

To define a successful sprint and get sign-off from team, the following flow was established.

Timeline is as follows. The following is based on a Wednesday to Tuesday Sprint configuration with weekly deliveries aimed on Tuesday.

  • 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.

As mentioned, this is more about THEORY then actual real world, but looks pretty, right?

Methodology of work

Based on priority of Stories established by PGM and client, the BA assigned to a given Tactical Team will breakdown requirements using both Confluence and/or JIRA, with final output of Tasks in sprints based on position of the associated Story. For example, story Summer Tablet Promotion II is in Sprint 10, all tasks will be added by the BA to Sprint 10 as well, with the Components properly configured so the tickets only displays on the appropriate boards.

Issue Management

You might have noticed that bugs and internal bugs (custom ticket type) is omitted from the sprint boards. This is on purpose. When planning, it is good to add a buffer to your team capacity to cover bug resolution on an as needed basis and is not generally managed in a specific sprint but independently by the developer(s). I will discuss further how estimations were handled in a later article.

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

Advertisements

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

  1. Pingback: Bring Calm to Chaos, a success story with Atlassian Tools (the introduction and power of Components) | Everything about Nothing in a world about Everything

  2. Pingback: Bring Calm to Chaos, a success story with Atlassian Tools (creating an JIRA Agile Sprint Board) | Everything about Nothing in a world about Everything

  3. Pingback: Bring Calm to Chaos, a success story with Atlassian Tools (creating sprints and the lessons learned) | Everything about Nothing in a world about Everything

  4. Pingback: Bring Calm to Chaos, a success story with Atlassian Tools (How we estimated) | Everything about Nothing in a world about Everything

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s