In the last article, “Sprint Management with Jira: Estimating Your Velocity” we discussed how to plan work for a Sprint. Teams may simply estimate their time in hours and while others might estimate in story points. We mainly looked at how this would take place during the Sprint Planning Meeting. These hours are estimated up front. ScrumMaster may want to know how many actual hours are used. Some Teams may bill for hours as used so they need to be precise with every activity they do. Others might only want to see how accurate the Sprint Planning meeting was in estimating Stories.
For this article, we will discuss how to use Jira to record the time you spend on an issue. In addition, we will discuss some of the AddOn options that can be used to give enhanced time keeping functionality and reporting.
Jira Software provides an “out of the box” solution to recording your time. Within an issue, select More > Log Work. You can enter the time that was spent in terms of weeks, days and hours. You can also set an Original Estimate that you can Log Time against.
Jira Software also has reporting to show estimated time vs actual time. While these reports do give information displayed by Version, there are limits to the information these reports will show.
Tempo TimeSheets provides an enhanced time keeping experience. The interface makes it easy to search for issues and enter time. Timesheets can be submitted for approval. Reports can be customized and created based on different criteria. Tempo also has Teams that members can be on. This creates an approver and team member structure allowing easy planning and approval.
Tempo Time sheets works great for Teams that need to report their time and can do so after an issue is completed.
Some Teams may not be able to record time after an issue is complete and may want a timer to run that can be started and stopped.
For those that use Jira Service Management – an SLA (Service Level Agreement) – provides time tracking that can start begin recording when an issue is picked up by an Agent and stop when an issue is closed. An issue might have multiple SLAs to track time such as Time to First Response and Time to Resolution. SLAs are customizable and you can choose criteria to start/stop and pause the clock on.
If you would like to use a Timer to record time used for Jira Software or even have other Apps such as Trello, Gitlab, and Monday.com to integrate time keeping functions – Clockify may be a solution. Clockify can be integrated with these apps.
For Jira Software, The Free version of Clockify uses an API key you can paste into each app. You can also set a webhook for notifications.
A View from Jira Software:
Monday.com uses an extension for a browser such as Chrome to link to Clockify.
A view from Monday.com:
While having an App like Clockify between different Cloud apps can be helpful – Managing many cloud apps with time keeping functionality can be tricky. It’s helpful to decide which apps will have time activities recorded and which will not.
Time Tracking can be helpful for many groups. Accounting and Billing may need to know the time spent developing software to bill a client. ScrumMasters may need to see how much to adjust the velocity for the time actually spent vs estimated for the next Sprint Planning meeting. Managers may need to know how much billable a development team worked on. Using time tracking at Jira or Monday.com can take the time out of time keeping for your team.
If you are interested taking your Team’s Agile Processes and Tools to the next level, contact Ascend Integrated.
Ascend Integrated is proudly partnered with Atlassian and monday.com mentioned in this article. Ascend Integrated can also develop Clockify integrations with your app suite. Ascend Integrated also has Gitlab configuration capabilities.
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.
We discussed how to use Atlassian Jira Software to plan work. We looked at some different AddOns to rate issues that are to become work items for a team by prioritizing which items are the most important to different interested parties. We then discussed how the developers on a team can assign a rating of complexity to a work item. This can help determine our Team’s capacity: What items to pull into a Sprint and how many items the Team can expect to complete.
We can now turn back to the Project Manager role who might be asking: When will a group of work items be finished? The best place to look for this information will be in Releases.
What is a Software Release?
Releases are groups of updates for software. They may contain Bug Fixes, New Features, Improved refactored code, or other changes. They are generally tracked as Versions (Ex. 1.0.0).
The type of software that a development team works on will vary greatly from organization to organization. Some types of software are loaded onto secure devices that are not always connected to internet and thus are updated infrequently. One example might be firmware for an industrial machine – it might require a programmer interfacing with a physical terminal to load the update.
On the other end of the spectrum, there is also software that can have constant releases at any time, because the software is Cloud-based and many users can have settings to continually look for and download updates. An example of this might be a Smartphone App. In some cases, there might be a new update every day. Some very large platforms might have thousands of updates a day performed in various systems without the end customer even noticing.
Another factor may be what types of completed work items will be in releases. Some types of software favor stability over all else. Pushing out bug fixes may be needed to be frequent and take precedent over features which might only be released once a quarter. Some types of software may use multiple environments.
A development team may consider a story “Done” when it is released into a QA environment but a testing team may only be starting its work. Some teams may only be able to test large batches of work at once. Others may be able to use automated QA testing which might allow a work item to be tested right away and promoted to the Production environment when it passes a test.
With this in mind this article will show how to use Jira Software and its AddOns for Release Management in different scenarios.
Examples with Available Tools
Each Team has their own Jira project which has its own Product Releases at the end of every 2 week Sprint:
Jira Software has a Releases module in which you can use to track the FixVersion (version that the Story or Bug will be in).
Jexo
The Jira Software AddOn – Jexo Swannly Roadmaps has the ability to add a Cross-Project Release. In this example: The Koala Team and Toucan Team are both putting items in their own Releases, but the Cross-Project Release is available for both Teams to add their Jira issues to. Swannly Roadmaps is available for Cloud versions of Jira. The colored bars represent Releases in this view and show both the releases the Teams have and a separate Cross-Project Release.
Another solution for Jira Software Cloud Premium or Jira Data Center is to use Advanced Roadmaps. Advanced Roadmaps creates Cross-Project Releases that both teams can use.
Example:
You have two Jira projects from two different Teams. They each need to work out of the same Release – a Cross-project Release called Q1 Banking Release. Each Team has a Q1 Features Release that needs to be tracked for their Team. These Team releases are part of the Cross-Project Release.
Like the name suggests, Jira Advanced Roadmaps provides a visual Roadmap as well. It is a hierarchy of issues that that shows visually when issues will be worked on. You can also add columns to show issue information and make changes that can synch with Jira Software.
monday.com
Product Roadmaps can be a way to visualize which issues will go in what Releases. This can be visualized in monday.com’sFeatures and Releases Roadmap:
While monday.com can be used as a simple standalone project management tool, it can also be integrated with Jira Software. Issues that are updated in Jira Software can be visualized on monday.com.
Coming Up Next
In this article we discussed how to visualize when work will be released. A release might be to a customer in the Production environment or to another environment like QA where the next step is Testing. Releases can be milestones in a Roadmap for a Team to achieve. Roadmaps are a visual way to see when items will be completed. Releases might be done “When Ready”, after a Sprint is complete, Quarterly, or at another set cadence. With Jira AddOns, we can also coordinate with several Teams by creating Cross-Project Releases.
While Releases can be tied to a Sprint, they do not need to be. Releases are meant to be for the end user or project stakeholder so that they know when their requested Features or Bug Fixes will be in the latest version. Developers need to know what Release they will complete a User Story in, but also they need to plan what Sprint a work item will go in. In the next article, we will discuss some different Sprint Planning methods.
If you are interested taking your Team’s Agile Processes and Tools to the next level, contact Ascend Integrated.
Ascend Integrated is proudly partnered with Atlassian, Jexo and monday.com mentioned in this article.
Part 1 – Prioritizing our work and determining its complexity in Jira
In our previous blog article, “HOW MUCH SHOULD I BUDGET FOR AGILE (AND OTHER FRAMEWORKS)?” we discussed the decision making process for making an investment into your organization’s Agile processes. Jira Software provides an excellent platform for developers to track their work items such as Epics and User Stories. Jira Service Management provides a Service Desk portal for external users to report a bug or suggest a feature.
This article will focus on which tools that can be used to support the initial planning process in Agile. Scum Masters, Product Owners, and others within an Agile Team see a list of work items in a backlog and ask the following questions:
What work item is the most important and needs to be done first (Prioritization)?
How difficult will each work item be to complete during the Sprint Duration (Complexity)?
Referring back to our Agile process, we can focus on the two main methodologies: Kanban and Scrum in looking at how the Team can plan its work.
Kanban
Agile Teams using Kanban Methodology are interested in constantly prioritizing work so that they can keep work moving and flowing. Important work items may need to be done as soon as possible or they can be de-prioritized and worked on later.
Selecting a Single Priority Level
Jira Software includes Priority Levels that can be used to signify importance. Additional priority levels can be added. But ultimately, simply selecting a dropdown like “Highest” limits how specific we can be. What does “Highest” mean? What work items should the team pull in next if several work items have the same Priority level?
Calculating a Priority Level
Jira Automation (available per Jira project in Jira Cloud Standard and Global/Multi-Project in Cloud Premium) can be used to create a Priority Matrix. You can choose other fields to set the Priority level by a combination of field values such as “Impact” and “Urgency”. For example, if a customer documenting a bug creates a ticket reporting the Impact as “Extensive / Widespread” and the Urgency as “Critical”, then the priority for the ticket is set to “Highest”.
Jexo Foxly Backlog Prioritization (available for Cloud as a Jira AddOn) has a comprehensive Priority Scoring system you can customize to assign a numerical value to make work items easier to sort.
You can display work in Priority Quadrants to determine which items are grouped into different priority levels.
Multiple inputs for Priority
One way to prioritize issues would be to know how a certain type of user might value a user story. Easy Agile Personas allows you to create multiple personas which can place a different priority on a user story. Rather than just the Requestor’s priority, any user can see how different Personas value a new feature. Viewing the Persona may also be helpful when developing the feature.
For KanBan methodology, once a developer is free to continue working, they will select a work item from the backlog. They can see the priority and will choose the next most important issue. While due dates are important, developers who work on Kanban style teams are trying to resolve issues as quickly as possible, For Bug-fixing focused teams, it can be important to resolve the most painful ones first.
Scrum
For Agile Teams using Scrum Methodology, teams need to have a backlog that is prioritized. This is done by a product owner working with a project manager and the customer. Using the same prioritization tools as previously mentioned, we now have a list of user stories that developers can select from a backlog to complete.
The developers will now know which work items are the most important to choose first. Rather than a developer continually pulling issues from the backlog onto their board, the Development Team will select several issues at once from the backlog to work on during their upcoming sprint period (usually 2 weeks).
Now, the developers have a job to do. They need to determine how many of these work items they can commit to developing on during the Sprint. It is important to commit only to what your Team believes it can finish during the sprint. This control gives stakeholders, customers, and the project manager confidence that work will be completed on time. To determine how many stories each individual on a team can commit to, we need to look at Team Sprint Capacity. Before we address Team Sprint Capacity, we are going to discuss Work Item Complexity.
There are many ways that an Agile Team can measure the complexity of a work item, but for the sake of this article, we are going to focus on Story Points.
Story Points are a numerical rating of how complex a work item is. An item is rated by a developer in the backlog from 1-8. For example a “1” rating might be a simple task with no research required, where an “8” might be a complex work item and with no current understanding for how to solve the issue. Research, trial, and error are likely necessary to complete the work item within the Sprint duration.
Setting Complexity with Story Points
Jira Software allows a user to put in the Story Points while in the backlog:
Calculating Complexity
One way to create multiple inputs for Story Points would be to use Jira Automation to calculate the number of Story Points based on other fields. For Example: If research is needed, testing is needed, and we are not sure of a solution, then the Story Point Estimate is automatically set to an “8”.
Planning Poker – Voting on Complexity or Priority
While some teams have individuals that tend to work on their own items based on their specific skill set, other teams may have multiple individuals with the same skills (poly-skilled) that could pick up the same issue to work on. Teams of this type might hold a Poker Planning Session. With Jexo Foxly Backlog Prioritization, we can invite several users to a Poker Planning session.
During Planning Poker, several Team members will give their own estimate for a Story. We might use the same variables such as “Research”, Testing”, and “Sure of Solution” as the previous example but instead of a Yes or No answer, each voter chooses a value between 1 and 8. The scale could consist of “1” being the least amount of effort up to “8” being the most difficultly. Similarly, a group of those responsible for setting work item Priority such one consisting of a stakeholder, customer, and product owner might each vote on their own priority level. A formula can also be used to determine how to score such as “Business Value” + “Customer Value” = “Priority Score”.
Setting the Story Points using the Priority score – Automation for Jira
It is also possible to use Jexo Foxly Backlog Prioritization in combination with Automation to set other fields. For example: If the Score for an issue is above 30, then Story Points will be set to 8.
Planning as a Team
In order to determine what your Team’s “Total Sprint Capacity” will be for the next Sprint during planning, we can look to the number of Story Points the Team has completed in the past. One place to look for this information will be the JiraVelocity Chart Report, displaying the total number of Story Points committed by the Team during the last Sprint and the total number of Story Points Completed by the Team in previous Sprints.
Coming up Next
So far, we have discussed how interested parties such as business stakeholders can prioritize issues in the backlog using Jira or with an AddOn that adds extra functionality. We have also illustrated how a developer can give a rating of complexity a work item (Ex. a User Story) that is to be developed. A Team can even vote on issues during a Poker Planning session to determine the Story Points or they can calculate them with Automation for Jira. In addition, a Team can can look to the Jira Velocity Chart to see how many Team Story Point they can expect to be able to complete in the future.
The next question in planning our work is: When will the items be completed?
Let’s break this down by what each interested party wants to know:
Customers – Most customers are concerned with when they are able to see the updates released to their Production Environment, regardless of when it will be worked on by the development team.
Project Managers – Most project managers have deadlines in the form of dates or milestones based on releases.
Stakeholders – Business Stakeholders want to know when the business will see value (confirmation that a new feature is released to the customer and the customer has accepted it).
We will discuss Release Management in our next blog article of our Agile series.
If you are interested taking your Team’s Agile Processes and Tools to the next level, contact Ascend Integrated.
Ascend Integrated is proudly partnered with Atlassian, Easy Agile, and Jexo mentioned in this article.
When an organization starts out its processes are loosely defined. Why complicate things? When there are few parties involved, communication can remain informal. It’s usually easy to get in touch with each other. Transparency is preferred because of the close relationships held with the people involved. In many cases this is often an advantage. There are few bottlenecks from endless rounds of approvals needed, and things can be done on the fly without the need to document everything. This allows workflows to be executed quickly. However, as a company expands to bring on more complex customers, hires more people, creates more teams, and hires individuals to manage those teams; things can quickly become much more complicated. Expectations can be increased unevenly across teams.
In many cases, individual teams are allowed to manage their own development process in their own silo. Sometimes different teams can adopt their own development tools as well. This can often happen in a situation where a new team is acquired through a merger and the newly acquired team already has its own processes and tools in place. The leader of the organization might see this growing chaos and feel the need to create order. Decision makers look up the Agile Manifesto and see: “Individuals and interactions over processes and tools.” Does this mean that we are “Agile” if everyone is allowed to do whatever works for them?
One of the common misunderstandings of the Agile Manifesto is that “Agile” means “Do whatever works for you.” But if we take a closer look at the phrase “While there is value to the items on the right, we value the items on the left more.” – we can come to a similar conclusion: While it is true that we value individuals and interactions more than we value processes and tools, that does not mean that processes and tools have NO value. In fact, poorly defined processes and the wrong tools can lead to individuals having more frustrating interactions with other individuals – their teammates, vendors, and in the worst event even customers.
The way to show that management values the time of their employees is to make the process for the worker more efficient. If Team A has Jira but Team B has Trello and their work has dependencies on each other, not using a common tool can adversely affect communication and thus interactions between the individuals on those teams.
Often when problems crop up and organizations look for efficiencies, what tools each team can use for development becomes a decision that is based on cost efficiency rather than team efficiency. Many times, when deliverables become delayed and communication breaks down, the first instinct is to bring in a new tool that all the teams can use. While this can help account for some disfunction an organization may face, in many cases the software development processes that are used by disparate teams become the cause of more problems.
Even if the CIO has taken the lead to bring multiple teams on the same development platform, they haven’t accounted for the process that must be followed now that everyone shares a common platform. While there is value in bringing in a new development platform like Jira Software – this is only one half of the necessary solution. It’s important to give users training on how to use any new platform. This is a necessary consideration so that teams can use the new platform effectively. It’s also necessary to train your teams on using a common development process framework (with some allowable customization between teams). While this all sounds great, as a CIO we think to ourselves: We are already spending some budget on the new tool – implementing the new software development platform – Jira Software. How much should be budgeted for processes?
Questions to Ask When Budgeting
Who in the organization owns the software development process?
How much customization of the software development process is actually needed by different teams?
Is it due to product differences or differences in delivery expectations?
Is there a way to measure our success and efficiency across different development teams?
Do we have any experience with the Agile framework development methodologies like Scrum and Kanban?
Have we put oversight roles in place to make use of these methodologies successfully?
Do we have an individual with the right expertise (and time they can devote to it) who is able to lead an effort to standardize our processes and measuring results across teams?
Does our current company culture accept change easily?
How entrenched are old habits?
Implementing Agile Methodologies
Empower Team Leads (or Scrum Masters) to form a Center of Excellence and own the organization’s Agile training: For this to be effective, you need very dedicated resources with the right expertise to lead the initiative. Often, it can be hard for these individuals to find enough time to work on the effort to go Agile. The Atlassian Agile Coach offers information and tips that your organization can implement.
Budget Agile Training into your training department’s program: If your organization has training classes, this can be a way to ensure that your associates at least have a day of classroom time devoted to learning Agile. While this can be a good start for those without Agile experience, it’s important to learn continuously. Ascend Integrated offers the Jira Essentials with an Agile Mindset class which both teaches how to use Jira and how to use the Agile Framework with Jira. For more information about Agile classroom learning contact Ascend Integrated.
Structured Agile Transformation: This would be a top down organization-wide initiative that places importance, time, and a monetary budget on developing the Agile Framework. This works best with hiring a third party agile expert with experience with multiple organizations and situations that can get measurable results without the need for an internal individual to have to devote time and effort. With a third party leading an Agile Transformation, they can also have the authority and ability to motivate others. Ascend Integrated can lead the way at your organization with Agile Coaching and Process Consulting.
Scaled Agile for Enterprise (SAFe) Implementation: This is the most comprehensive methodology. Plan for a minimum of at least a half year (two quarters). For companies with 125 individuals or more, this can be a way to manage both individual teams and teams of teams. An outside third party leads the implementation and helps develop the organization’s individuals who will be owning the agile process in the future. Ascend Integrated is a Scaled Agile for Enterprise Bronze Partner and can enable a SAFe transformation with using the Jira Software suite or other tools at your organization.
For more information to help determine what the best path to Agility would be for your organization, contact Ascend Integrated. Ascend Integrated is a Atlassian Partner.
Reviewing FBO.gov and the GSA Ebuy portal, there are currently close to 300 open opportunities across the Federal government for the implementation, development, or management of agile processes and procedures. Tools used to enable and reinforce these processes are also abundant on the marketplace, but how can you select them in order to correctly meet government security standards? The documentation requirements often found within these government needs, including FedRAMP compliance, can be prohibitive without context. This blog will discuss tools currently available on the marketplace that meet FedRAMP compliance, while enabling agile processes across your organization, and can be integrated simultaneously to create even more sustainable managerial solutions.
Enabling Agile with Multiple Tools
It’s no surprise there are a range of toolsets on the marketplace that enable agile processes. However, many of these exist in a non-compliant cloud state and are rendered inaccessible for government users. Problems arise either through authentication, authorization of use, permissions, or from a general security and vulnerability standard. Three tools we are going to discuss today which can be hosted in FedRAMP compliant environments include:
Atlassian Jira Software
Atlassian Confluence
GitLab
All three have some overlap in surface capabilities, but when combined they provide a deep functionality for enabling agile processes.
Jira Software + Confluence
The Atlassian Tool Suite (Jira Software and Confluence) has been successfully used for over a decade across multiple Federal organizations. The products have been deployed across FedRAMP Low – High environments and enable multiple work environments to run effectively with diverse solutions. Using Jira Software, project managers and SCRUM masters are enabled to properly manage tasks and user stories, estimate and create sprint burndown charts, and track and manage the development of solutions across simple and complex workflows.
Confluence provides the wiki collaboration and documentation feature, often replacing SharePoint in agencies as the de-facto documentation tool. In unison Jira Software and Confluence enable traceability across written documentation networks and requirements along with deployment capabilities.
GitLab
GitLab is the end all, be all for application development. From inception to operation, usability is intuitive, and maintenance is easy to keep up to date. It provides users the capability to host a code repository that allows team leaders to actively track and manage development stories, tasks, and implementation all while utilizing the underlying DVCS. GitLab also enables collaboration through the use of wikis, and can be hosted across different low, medium, and high security environments simultaneously.
Jira + Confluence + GitLab
While these services can provide incredible capabilities on their own, covering multiple functionalities under the DevSecOps tool chain, the true power of their scope is realized when they are combined. When this set of tools is applied together users are empowered to accomplish more through utilizing the main strengths of each tool, specifically:
Jira Software: Project Management and tracking
Confluence: Wiki documentation
GitLab: Code repository, CI/CD, and deployment capabilities
Jira, Confluence, and GitLab can be synchronized together easily using multiple add-ons and apps from the marketplace. Many are free, while others carry a licensing cost to attach them. Enabling GitLab and Jira provides you with a full view of Tasks, Bugs, and User Story development in the Jira work environment. While documentation is developed in Confluence, including Branches / Commits / Merge Request information, and notes in GitLab.
These tools when combined, create a functional strength in their unison. It is the combination that allows each tool to work more effectively for a wide range of common organizational needs. And most importantly, these tools can be deployed across multiple Federal and Commercial organizations in a variety of network conditions and implemented in preapproved FedRAMP environments. Implementing and enforcing Agile processes is essential in your Federal Agency. Jira, Confluence, and GitLab combined provide not only these capabilities in a secure environment, but also possess all the functionality required to keep your agency on the cutting edge of available technology.
Conclusion
How are you enabling Agile in your organization? Feel free to reach out, comment, or drop us a line and let us know! www.ascendintegrated.com
