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.

Lesson 1: Shared Sprints

When you create a sprint in one sprint board, it is actually tied to not only that sprint board, but to the actual JIRA project itself.  Why is this significant you might ask? This means that if you create a sprint in one sprint board, then assign a ticket from another sprint board, that sprint will appear in both sprint boards. But if you create a sprint in one sprint board and no issue tickets from another sprint board is mapped to that sprint, it will display only in that first sprint board and not the second one. Got it?… no? yea me either, I’m a visual guy so let me provide you some visuals 🙂

Let’s first set the stage in which we have 3 sprint boards

  • Sprint Board A, has no filter and displays all tickets
  • Sprint Board B, has a filter that displays a subset of tickets
  • Sprint Board C, has a filter that displays a different subset of tickets

All 3 sprint boards relate to the same single JIRA project

SprintBoardsOnlyNow we will create a new sprint (I’ll discuss further down in this article how to create a sprint in JIRA Agile) in Sprint Board A

SprintBoardASprint

I’ll take tickets from the backlog and apply it to Sprint 1. Now if these tickets are not included in the filter for Sprint Board B or Sprint Board C, the Sprint 1 will only be seen in Sprint Board A, but in our example tickets we added to Sprint 1 in Sprint Board A are also displayed in Sprint Board B but NOT in Sprint Board C, as a result, we will see Sprint 1 in BOTH Sprint Board A and Sprint Board B but NOT in Sprint Board C:

SprintBaordABSpritn1You can add tasks to Sprint 1 from either Sprint Board or Sprint B and it is reflected in both. This method is great for in the solution we created for our recent Fortune 100 client as described in our theory behind the solution, where we had one sprint board dedicated for planning, another sprint board for shared resources and individual sprint boards for our silo’d teams.

Lesson 2: Hidden tickets

In a perfect world, everyone uses the tools given in perfect fashion. That means they do not start work on tickets unless they are in a sprint, but, alas, not everyone is law abiding citizens of JIRA.  One lesson we learned is that if someone works on a ticket that is in a “Future” sprint (more on what that exactly means in JIRA later) that ticket is “hidden” (not displayed) in JIRA plan mode. This can cause surprises when that future sprint is ready to be worked on and you click Start Sprint, these tickets will suddenly appear. This can also be painful if you want to delete a sprint because JIRA will error if you have any tickets in the sprint but you may not notice if they are marked as resolved or closed.

The best solution (besides mentoring the individual who made the error) is to verify no tickets in this case using issue search in JIRA.

  1. Open Search for Issues under the Issues menu:
    SearchforIssues
  2. Now we will select a few settings in “Basic” mode. This includes:
    1. Select the appropriate project
    2. Click on More and select Resolution, then in Resolution menu select Unresolved this will retrieve all tickets that have not been set to Resolved or beyond depending on your workflow
      Unresolved
  3. Now click on Advanced on far right, notice a JQuery is displayed:
    JQuerySample
  4. We now add to existing JQuery the sprint we want to check. To do so, type:AND Sprint =
  5. Now begin to type the name of your sprint and a menu should automatically display showing possible matches, select the sprint you want to include. NOTE: this will show not only sprints that are in the project you selected but any sprint you have access to in JIRA.
    SprintMenu
  6. When you select your appropriate sprint, it will automatically be converted to an internal sprint ID, don’t be scared, it is just that the query uses internal ID since the display name can change any time, and will preserve the integrity of your query in the long term.
    SprintID
  7. When ready click the search icon to see all related tickets.
  8. if you have a handful of tickets you need to remove from the sprint, you can go ticket to ticket, edit the contents and clear the contents in the Sprint attribute. If you have a lot of tickets in this case, Bulk Change might be a better solution.Single Ticket Update
    ClearSingleTicketAttribute
    Bulk Change
    ChangeSprintClearContent

How to create an actual sprint

I do have a 3rd lesson learned I’d like to share, but let’s first discuss how to create an actual sprint first. If you remember in an earlier blog, we created 4 separate sprint boards:

  • Collective Team Board
  • Scope Planning Board
  • Platform Team Board
  • Production & Marketing Team Board

Based on the experiences we mentioned above, it is best to create each sprint in the same sprint board for easier reference and management. Since Collective Team Board has no filters, it is the best location to create the sprints. In Plan View (note that in latest release of JIRA Agile, it is now called “Backlog”) locate and click the button Create Sprint.
CreateSprint1

You have now created your new sprint!

newSprint1

You can modify the sprint name by clicking on Sprint 1 in top left corner (note that there is a 30 character limit for sprint name), add tickets to the sprint by drag and drop from your backlog, or generate additional future sprints. This leads us to our next lessons learned…

Lesson 3: Managing future sprints

It is always good to manage the future. JIRA Agile Sprint Boards support this through creation of future sprints where you can create new sprints in a sprint board that are not marked as active but “future”. This lets you go ahead and start adding tickets and perform necessary estimations based on team capacity and priorities. But priorities can always shift significantly. When you create a new sprint in the sprint board, it appears at the bottom of your sprints in a stack formation top down:

  • Active Sprint
  • Future sprint 1
  • Future Sprint 2
  • Future Sprint 3

if you create a another sprint, it will appear below Future Sprint 3. example is shown below

newSprintorder

Problem is, when you start your next sprint, you can only start the one at the top of your future sprints. In our example below, I need to start my MSCN – Product On Board sprint instead of MSCN – Sprint 41 due to priority shift.

StartDifferntSprint

Unfortunately the only way I know how is to shift all existing tickets in each sprint down by one sprint using Drag and drop method, then move contents of the MSCN – Product On Board into the next future sprint at the top.

I hope the details I provided gives you some insight into creation of sprints and lessons learned related to the sprints.

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

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

  2. Pingback: Bring Calm to Chaos, a success story with Atlassian Tools (the theory behind the solution) | Everything about Nothing in a world about Everything

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

  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