We discussed how to use Atlassian Jira Software to track releases. For Teams that contribute to a release across projects, there are tools such Advanced Roadmaps and Jexo Swannly Roadmaps that allow for cross-project releases. You can view your team’s releases on a timeline with dates in a roadmap.
Now that you have organized your work, you are ready to determine which Sprint these work items will go in. During the Sprint Planning meeting, we will need to determine how much work the Team can commit to this sprint and plan for the next sprint. The amount of Story Points that a Team can complete during a Sprint is called Velocity.
Part 3 – Sprint Management
For this article we will look at how to manage a Sprint if your Team uses Scrum.
Jira Software
Jira Software allows you to drag issues from your Backlog into the Sprint.
In order to determine how many Story Points the team should commit to in the Sprint, we can run the Velocity Report and see how many Points were committed vs completed in the last Sprints.
In the above chart, we might see that the Team committed to 15 Points in the last Sprint and Completed all of them, so maybe we can increase the velocity a bit, assuming nothing else with the Team has changed.
Advanced Roadmaps
If you are using Advanced Roadmaps (included with Jira Cloud Premium or Jira Data Center), you will have an updated Velocity Report that will display the Average Velocity that your Team has completed based on previous Sprints. In the example below: The Team has completed an average of 19.33 Points, but the Team has been committing more than 20 Points per Sprint.
In our Advanced Roadmap Plan, we can use the Sprint capacity management view on the Roadmap tab and view the upcoming Sprint:
We can set the average velocity for the Team to zero. In this case, as we plan we can see that we only have 13 Points worth of work committed to the Sprint, and we have room for 7 more points worth of work.
Monday.com
Jira Software does have both a field for Story Points and Story point estimate. This allows a team to input the amount of points they initially thought the Story was worth and update the Story once completed with the amount of Story Points the story was actually worth. This can help a team estimate better in the future. While the Jira Velocity Report can only show Story Points, if your Team integrates Monday.com and uses the Sprint Planning template, you can view a summation of both Story Points (SP) and Estimated Story Points (EP).
Easy Agile
While it’s possible to run parallel Sprints for the same project in Jira, many Teams wish to plan several sprints ahead. This can create a lot of scrolling in Jira if you have a sizeable backlog and many Teams using the same project, this can be cumbersome.
Easy Agile Programs for Jira allows the creation of Program Increments (PIs). Within a PI, a Team can drag the items into each Sprint as projected all on the same screen. Dependencies can be visualized on the board.
In this article we showed some ways to plan Sprints using Jira Software or an AddOn to make use of Velocity to plan your Sprints. We can also view the difference between Story Points that were chosen at Estimation vs the amount of Story Points completed. It’s also possible to plan several Sprints ahead.
Story Points are a great metric to track how much work is being completed. But often times, we still need to track the amount of time an issue takes to complete. In the next article in the series, we will explore Time Tracking.
If you are interested taking your Team’s Agile Processes and Tools to the next level, contact Ascend Integrated.
Earlier this year, I was tapped to create and manage our client service portal here at Ascend Integrated. Looking back at my prior experiences as both a guide for what not to do and an inspiration for how to elevate the customer experience, I began to recall my first foray into ITSM outsourcing.
A decade ago, in another life, the fin-tech startup I had been working at for the past few years hit their stride and began a period of rapid growth expansion. It was an exciting time and the future seemed bright. And bright it was, so bright in fact that we had to wear shades.
The influx of new clients revealed a host of underlying issues that had gone largely ignored in pursuit of growth and investment. In order to succeed we needed to adapt, create efficiencies, and automate fluidly. One of the areas that needed to scale quickly was the client experience, primarily the workflows surrounding internal service level agreements (SLAs) and external communication.
It quickly became clear that we needed a better method to track and respond to client requests, questions, and issues as well communicate internally. Thus, the search began for an ITSM solution that would meet the needs of the entire company.
After weeks of demos, sandbox testing, and internal discussions, a vendor was selected and we began down the road to implementation. As soon as we did, however, we hit a major roadblock. The software’s feature suite was known in addition to the general idea of the efficiencies to be developed, but we hadn’t pictured what our ideal system looked like.
Up until now, most departments operated in silos with most of the workflow determined by direct managers. Change had to occur, but what those changes would be and how they could be unified were still unknown.
At the time, we chose to develop our new ITSM solution in-house. We thought, “Hey, we’re a software development company with internal Engineering teams and lots of smart people, we can figure this out easily.”
There were constant speed bumps and growing pains along this journey. It took the better part of a year and an extremely patient client as a beta partner, but we did eventually get our system rolled out and scaled for hundreds of client organizations.
And still, after all that planning, testing, and effort, clients were hesitant with this new method of interaction when it was initially introduced. They were apprehensive that instead of picking up the phone, they would submit a ticket via a client portal. It seemed too impersonal. There was concern that the service level would decrease with this new approach. The list of hesitations was long and getting buy-in took time.
Ultimately, what sold these clients on this exciting new product were the efficiencies they were seeing in real-time. Communication improved, response times to requests became shorter, fewer items were lost in the shuffle of emails, and internal staff was able to focus more on the client leading to a net-positive experience for everyone involved.
Today, there are many more tools and cross-product integration providers. Navigating the jungle of vendors can be daunting to say the least. A constant in the ITSM space is change. The way both teams and systems are managed are unique to each organization, as are the expectations for success. Both will continue to change with time and growth.
Though over ten years have passed and the sophistication of ITSM software has grown exponentially, the reasons behind necessitating these tools remains the same. Regardless if your company has a staff of 10 or 100,000, in order to be setup for success, it is advantageous for staff needs to be able to focus on the client and the work product above all else.
I’ve occasionally reflected about what I would change if I could change one thing about that initial experience. The conclusion was that I wished our company had the guidance of subject matter experts who brought an outside perspective and a wealth of experience along with them to simplify the process and help conceptualize a needs-meeting product.
I’ve worked in a wide array of industries throughout my career, but before my time here at Ascend Integrated, I didn’t know I was missing a piece of that answer. The staff at Ascend are a real team and that carries over to all of our clients. We don’t support each other just because we’re a team; we’re a team because we support each other. Our customers are part of our team, and that’s what makes us exceptional.
