Happy (almost) New Year! Like most people, I was happy to close the door on 2020 and am ready to move past 2021. Thankfully, 2021 brought some relief, but even still it was another challenging year. While I'm grateful for the growth both professionally and personally that each year provided, I have high hopes for 2022 and that it’s not “twenty twenty, too”.

Every new year provides us the opportunity to retrospect on the previous year and plan for the new one. I, for one, do not make New Year's Resolutions. Several studies show that only 8% of New Year's Resolutions are successful. The reasons for failure range depending on the group of people surveyed. Athletes, for example, have a fateful day: the second Saturday in January. Whereas others may see a slightly longer time frame before failure (the second week of February), it's disheartening to set and fail at a New Year's Resolution.

Each of the studies (of which there are countless) seem to agree on the success factors: setting smaller, attainable goals in shorter time frames. For those Agile evangelists out there, this sounds VERY familiar.

Setting SMART Goals

The first step in setting any attainable goal is to think SMART: Specific, Measurable, Attainable, Relevant, and Time-Bound. Roughly 55% of New Year's Resolutions are health-related. Let's look at one of the most common examples: "I want to lose weight."

When we hold this basic statement against the SMART standards, it fails. And, to be honest, so will you. Instead, let's reframe this within the SMART framework: "I would like to lose 20 pounds by May 31."

This fulfills all the SMART criteria of setting a good goal. Now that we have a good goal, how do we attain it? Let's look at our Agile frameworks to help us fulfill our goal of losing 20 pounds by June 30.

Set Yourself Up for Success: An Iterative Approach

If you've ever tried to fulfill a New Year's Resolution, you know there are tons of factors that can impact your results. Weather, holidays, birthdays, sheer lack of desire...any or all of these can impact your ability to attain your goals. Instead, break these down into incremental smaller goals and measure your attainment in shorter timeframes. Think of your big goal as an Epic (the what) to be broken into Stories (the how), and you will attain that goal.

The Epic: 20 Pounds in 5 months

The Stories: 4 Pounds per Month

See? Doesn't that already sound easier? But you need to take it even further. Thinking of each month as a Sprint, you should set yourself a Sprint Goal for each month. How are you going to build better habits to lose the 4 Pounds per Month?

• Walk 30 minutes twice per week
• Reduce meal delivery service to once per week
• Cook a vegetarian meal once per week

However, the critical thing to remember is not to start your first week with all three. Remember, you're trying to set yourself up for long-term success. It should look something more like this:

• Walk 30 minutes twice per week by the end of January
• Reduce meal delivery service to once per week and continue to walk 30 minutes twice per week by the end of March
• Cook a vegetarian meal once per week, continue reduced meal delivery service, and continue to walk by the end of May

Instead of starting all three goals at the beginning of January, gradually iterate into them. Spend the time to focus on a single, smaller attainable goal to build the habit.

Meet Your Goals: Measurement and Retrospective

While attaining your goal is binary (I did it or I didn't do it), the key to success is to measure against it and retrospect on a regular cadence. Instead of obsessing over the pounds per month, measure against the smaller goals.

• Walk 30 minutes twice per week
  • Mark on a calendar when you walked each week
  • Use a fitness tracker and specifically call out when you walked each week
• Reduce meal delivery service to once per week
  • Set the day of the week to have food delivered (e.g. Thursdays)
• Cook a vegetarian meal once per week
  • Mark on a calendar when you cooked a vegetarian meal
  • Set the day of the week to cook the meal

Each week, take a moment to review your calendar or your app or however you track these items. However, do not beat yourself up if you missed a week. Really dig into why the miss happened. Was it a particularly stressful day and ordering delivery was easier? Was the weather too cold or snowy or rainy that week? Either way, you don't have to "make up for it" the following week: simply try again.

As you engage in 2022, remember you don't have to start on your resolutions right away either. If you've failed every year in January, then shift your goal to a February start. After all, the definition of insanity is doing the same thing over and over and expecting a different result.

Interested in how you can apply similar logic to meet your business goals and increase your ROI on projects? Reach out and our experts would love to help.

No, seriously: can we please take a moment to talk about spreadsheets? I have a very large bone to pick with them. Spreadsheet is a four-letter word to me; and don't get me started on workbooks! I recognize spreadsheets have their place in the world. I'm always in awe when I see the most complicated and fragile spreadsheet being used to manage a simple set of data to provide "insights" into the business. Even better, a spreadsheet that helps manage prioritization, planning, and execution reporting on a regular cadence. I've seen complex CountA and SumIf formulas, and Concatenate, and pivot tables, and everything else people can throw at them. And while I'm impressed at the craftsmanship, I'm also incredibly frustrated. The time it took to create and iterate on that reporting could have been spent having conversations about the work or checking in with a team or removing blockers. Instead, the extraction, manipulation, and reporting of easily-accessible, real-time data takes precedent. 

While it was published in 2014, I still reference an article when discussing data and reporting with our clients: This Weekly Meeting Took Up 300,000 Hours per Year. Yes, you read that right: 300,000 Hours. Per. Year! A single team extracting data, then aggregating it across several teams, then teams of teams, then programs, then everywhere else, all to be reviewed in a 30-minute executive meeting where the conversation was, "Are we on track? Yes? Great."  <sends weekly update deck to recycle bin>.

I hold no ill-will to the spreadsheet warriors out there. Instead, I view it as a simple case of "We've always done it this way." Well, what if I could show you a different way? What if, through the power of Atlassian, I could provide you real-time analytics? What if I could show you how to integrate Jira with a Business Intelligence solution? Or provide Program and Portfolio Management including planning and execution data in Advanced Roadmaps or Jira Align? How many hours would that save you or your organization when providing in-depth analytics to executive management? I promise you, this is all possible. 

Individual Team Metrics: Scrum and Kanban

Individual Team metrics are available for both Scrum and Kanban Teams under Reports in a Jira Software project. For Kanban Teams, both the Cumulative Flow Diagram and Control Chart provide flow metrics for the Team. While it may have been a while since you've taken a statistics class (if at all...I confess I tried hard to avoid them), spending ten minutes reviewing these reports will provide information on bottlenecks, flow trending, and backlog growth. Adding Quick Filters to your Kanban Boards will allow you to drill down into a specific subset of data on your board. Want to focus on Stories or Bugs only? Create the Quick Filters. 

Scrum Teams have nine (yes, NINE) reports available on their boards. Are you using the Burndown during your Daily Standup? Can you predict your release of an Epic or Version based on the throughput in those reports? Have you reviewed the Sprint Report to see what was added or didn't complete during the Sprint and asked why? The Scrum Reports will tell you what is happening during the Sprint (or happened, during the Retrospective), but it's up to you and the Team to ask why it happened. 

Need additional assistance to understand what these metrics are telling you? There's a training class for that. Praecipio Consulting is happy to help!

Program, Product, or Teams of Teams Metrics

Client: "Hey, Amanda, we're pretty good on the individual team stuff. Is there another way we can aggregate team data together?" 

Me: "How much time you got?" 

Three solutions come to mind for this one:

First, let's talk about Advanced Roadmaps for Jira. As always in the Atlassian tools, flexibility is key. When creating a Plan in Advanced Roadmaps, tying the work to the Teams by pulling in the scope of work is the first step. Whether it's a Board, a Project, or a Filter, aggregating data across multiple Teams, then tying the source to the execution team, provides you predictable velocity and capacity planning as well as execution reporting. 

• You want Progress? You got issue count and story point or time-based progress.
• You want to predict a milestone (read: release) date? You got milestone dates.
• You want dependency maps? You got dependency maps.
• You want to look at the Plan in a capacity view or a release view or a specific timeframe? You got custom views. 

Sharing all this information from Advanced Roadmaps in Confluence is amazing. While native in Confluence Cloud Premium, you can download and install the free app from the Atlassian Marketplace for Data Center. If you would prefer to simply share a link to the specific view of the Roadmap, that's available to you as well. 

Second, EazyBI. We constantly hear of clients looking for a more robust way to cube and concatenate data across their Jira instance. However, our clients tend to revert to what's comfortable: the spreadsheet. Instead, using an OLAP analysis and multi-dimensional calculations, EazyBI can provide the complex reporting when Jira's native Reports and Dashboards just won't do. EazyBI started as a purpose-built solution for Jira: it recognizes Jira's data structures and surfaces field data you may not be able to work with in native Jira. Since it's a unidirectional sync, EazyBI will not change your Jira data either. EazyBI can also integrate with other data sources including (sigh) a spreadsheet. 

Third, Jira Align. Here at Praecipio Consulting, we love Jira Align. The Program Room brings together all the information from multiple teams, i.e. an Agile Release Train. Every bit of data from Jira Software is aggregated to provide a clear understanding of the pace of the Train. The Program Board, the current implementation Roadmap with risk indicators, the investment data, the actual execution data, all of it is available in the highly-configurable Program Room. Burnups, Burndowns, progress by Epic, this is all available in Jira Align. In fact, there are over 180 reports available in Jira Align. And if that's not enough, Jira Align BI extends the already-robust reports into your existing visualization tools or your enterprise data lake. 

Enterprise Business Intelligence Integration

You may already have a Business Intelligence solution. Quite frequently at Praecipio Consulting, we hear our clients mention PowerBI, Tableau, or data lakes such as Hadoop or Snowflake. These powerful solutions are likely already embedded in your organization. And there's probably a SME out there just waiting to assist. Enterprise organizations usually have an integrations team to help connect Jira and other data sources. In fact, we worked with a large organization to consolidate Jira instances to better connect data to their business intelligence platform. In just 12 short weeks, they were able to analyze and report on their current execution progress simply by being able to feed consolidated Jira data into their business intelligence platform. 

At Praecipio Consulting, we have extensive integrations experience across a wide-range of technologies. We can recommend Atlassian Marketplace apps as a fit-for-purpose solution or we can work with third-party integration engines to help you map data for enhanced metrics. 

Take a moment to step back and really examine your use of spreadsheets. While, again, they have a purpose in this world, to a hammer, everything looks like a nail. The spreadsheet is dead. Long live the spreadsheet. 

A couple of years ago, in Atlassian's annual flagship event formerly known as Summit and now known as Team, I was in a room full of people for two days providing training on Advanced Roadmaps for Jira on behalf of Atlassian. If you've never attended a live Summit event, the Kickoff Keynote is always a sight to see. One year, Scott and Mike dressed as Daft Punk and mixed music as DJ Kanban (I still nerd out on that one), you see announcements about the expansion of Pledge 1%, and, of course, new product announcements. Jira Align was acquired by Atlassian and announced at Summit 2019. I. Was. Floored. You see, we here at Praecipio Consulting were looking for a larger agile-at-scale solution for some of our largest clients. 

Enter Jira Align

After becoming a SAFe® Program Consultant (SPC) in 2015, I spent a lot of time with clients understanding intake and execution processes and facilitating them through the Atlassian product suite. These clients were either just starting their SAFe® journey or had been the earliest adopters and already implementing SAFe®. After implementing Advanced Roadmaps (then known as Portfolio for Jira) to support SAFe®, becoming the Atlassian University On Demand "voice" of Planning with Advanced Roadmaps, and guiding the course content with Atlassian, I was in love with Advanced Roadmaps. And I still am. Advanced Roadmaps is a powerful data aggregation, roadmap, and scenario planning tool for small- to medium-size organizations either as standalone entities or within an Enterprise organization.

Jira Align, however, brought forth a whole new realm of possibilities. Bringing robust framework expertise and combining it with an easy-to-use interface, Jira Align is THE solution for Enterprise organizations running agile-at-scale. Don't believe me? Atlassian is considered a Leader in the Gartner Enterprise Agile Planning Tools Magic Quadrant as of April 2021. Experience and third-party accolades aside, why is Jira Align so amazing? Let's take a closer look. 

Jira Software Integration

Unlike Advanced Roadmaps, Jira Align is a standalone product hosted either in multi-tenant or single-tenant cloud infrastructure. While there is an on-prem solution, of course, there are a lot of additional considerations if you have to choose this deployment. The connection between Jira Align and Jira Software supports both Data Center and Atlassian Cloud instances. The most critical part of the integration is the Jira Software Epic. Epics can be created in Jira Align and pushed to Jira Software or created in Jira Software and pulled into Jira Align. Keep in mind, when creating the integration, best practice is to isolate Epics into their own Jira project. Bringing in Stories and Sprints is also easier if a Jira project represents a single team. 

Rooms at Every Level

Whether you're just starting out with a single Agile Release Train (ART) or are running multiple ARTs, Jira Align provides the Program Room for each ART. This is the central hub for tracking the current Program Increment (PI) and planning the next one. Sprint Progress, investment runway, intra-ART and inter-ART dependencies, PI Burndown, it's all centralized within the Program Room. This provides Business Owners, RTEs, and Program Managers a clear view of the progress of the work in the PI. 

Jira Align also provides the Portfolio Room and Strategy Room. These rooms provide the progress towards Strategic Themes, Portfolio investments, progress toward long-term goals, and status updates. When properly connected to Epics in the Program room, Teams and ARTs can open the "Why?" tab on the Epic and see how their work is contributing to the overall strategy. 

Everyone's Favorite: Reporting

Jira Align has over 180 out-of-the-box reports. Each layer in Jira Align has a Track section pre-populated with the more popular reports for that section. For example, in the Program section, Jira Align provides Program Increment tracking, Program Increment insights, and Dependency Maps. If you're not sure what type of report you're looking for, simply click the Reports menu and ask a question in the search box. 

For those organizations that need to integrate with other systems or need more robust business intelligence, Enterprise Insights can be added to Jira Align. 

Want to know more? We here at Praecipio Consulting would love to walk you through how Jira Align can support your agile-at-scale transformation. Contact us!

Have you heard of Jira Align? I feel like we've told you about Jira Align. Maybe a few times. We here at Praecipio Consulting can't say enough about it. Its ability to manage agile-at-scale for enterprise organizations is unmatched. 

When implementing Jira Align or expanding your footprint, however, it's important to understand the objects in Jira Align, as well as their definitions. It's also critical that your organization agrees on these definitions as a whole. With that in mind, let's discuss the Portfolio in Jira Align. What it is according to the product, and more importantly, how to define it in your organization. 

What is a Portfolio in Jira Align? 

A Portfolio supports a value stream. What is a value stream? It's a specific set of solutions that deliver value to your customers whether internal or external. Where a lot of organizations make mistakes is thinking that a Portfolio is a grouping together of projects that need to be complete in a fiscal year. There is no regard for strategic alignment to themes, no consideration for investments, and may follow a business-unit-esque structure. This is NOT how agile-at-scale frameworks define Portfolios, nor how Jira Align defines them. In addition, Programs (aka teams of teams or Agile Release Trains) support a Portfolio. This ties the execution to the strategy in Jira Align. 

In Jira Align, a Portfolio has the following things: 

• A Strategic Snapshot
• One or more Program Increments (PIs)
• A budget for the Snapshot
• Strategic Themes with allocation to PIs
• PI budgets established
• PI budgets are allocated across the Programs
• Blended rate established for the PIs
• PI budgets, per program, have been allocated to Strategic Themes
• Portfolio Epics are created and have been connected to a Strategic Theme, scored, swagged, budgeted, and targeted to one or more PI

Ok, that seems like a lot, right? And it is. In the words of Antoine de Saint-Exupéry, "A goal without a plan is just a wish." While you may have established goals (e.g. increase new subscriptions by 15% over last year), without tying goals to the PIs, allocating a budget, then creating Portfolio Epics, you have a wish, not a plan. 

How Do I Define a Portfolio? 

Depending on your organization, you may have to take a step back and really examine how you operate. There are many questions to ask your organization: how do we deliver value to our customers? Which programs support the value delivery? Are these programs truly cross-functional and able to deliver from idea to value in the hands of the customer? 

At Praecipio Consulting, one of our Portfolios is Client Delivery. This Portfolio delivers value to our clients by providing professional services around the Atlassian products and complimentary technologies. The solution (professional services) drives the definition of the Portfolio. Our Client Delivery organization is the delivery mechanism and is grouped into two delivery programs: technical and process. While these are not mutually exclusive, they do require specialization on the part of the teams depending on the services needed from the client. 

Can you break your value delivery, solutions, and execution mechanisms in the same way? If you're struggling to do so, it may be time to reevaluate your organization's definition of a Portfolio before defining it in Jira Align. 

Once the Portfolio is defined in plain language, then examine which Program(s) will execute against the Portfolio. Remember, a Program is a team of teams organized around the value delivery of the solution to your customers. The Program operates in their cadenced PIs, creates and ties Epics and Stories together to the Portfolio Epics to estimate and complete work. Without these links, you will not be able to understand your progress, investments, or overall health of the Portfolio in Jira Align. 

Reporting on the Portfolio

I know I've said this before, but there are over 180 reports in Jira Align. However, the most commonly used object is the Portfolio Room. There are three tabs in the Portfolio Room out-of-the-box: Financials, Resources, and Execution. In all three views, you will always see the Program Increment Roadmap. This gives you an understanding of the planning and progress of the PIs.

• The Financials tab provides Budget by PI, Estimates, and Actuals in a single glance as well as Theme Effort vs. Value and Theme Budget Allocation against the ranked Theme Priority. 
• The Resources tab provides allocated resources by theme based on estimated work in the PIs as well as team-week allocation Theme Effort Distribution against the ranked Theme Priority. 
• The Execution tab provides Theme Progress, Points, and team-week efforts as well as Theme Burnup based on the number of points accepted. 

Of course, the Portfolio room is configurable based on the KPIs relevant to your organization. And a Portfolio manager can drill into any or all of the items listed above in further detail either by a specific PI or multiple PIs. Simply update the Program Increments you'd like to focus on and the Portfolio Room will update the data specific to those timeboxes. While Jira Align will suggest reports under the Track section of the navigation menu, again, you can simply ask Jira Align to provide the report you need under the full Reports section. 

Jira Align makes it simple to understand the health of one or many Portfolios in your organization. Best Practice is to start with one, iterate until you get it right, then expand across other Portfolios when ready. Praecipio Consulting's deep expertise with agile-at-scale frameworks as well as intimate knowledge of Jira Align can provide you the needed support when you're ready to take your teams to the next level: contact us and see if Jira Align is a good fit for your organization.

At a recent Atlassian Community Event, I was asked to present on a topic of my choice. After some thought (and to be honest, a poll to our Client Delivery team), I decided on Release Management using Jira. It's a frequent topic of discussion with our clients: how can I understand what will be or is released? Also, what changed between what was in Production to what is in Production now?

I've seen many complicated solutions and I've seen many simple solutions. However, your team, your company, or your organization has to hash out the following: 

• What is your definition of "Done"?
• What is your definition of "Release"?
• Are these two things in conflict? 

Definition of Done versus Definition of Release

As you may already know, in Scrum, "Done" is when the Product Owner accepts the story as complete, meeting all acceptance criteria, and packaged into a potentially shippable increment. While I agree with this definition, at the same time I challenge the phrase, "potentially shippable." This is where you, your teams, your operations teams, and your product managers need to have a conversation. Does "Done" and "Released" mean the same thing across your organization?

In one organization, they had four definitions of done: Done, Done-Done, Done-Done-Done, and Done-Done-Done-Done. In reality, they were defining the QA, deployment, and Production Release processes with the four separate definitions of "Done". This was also directly related to their use of Jira Software and how to demonstrate success to management. Notice I said success and not progress. The Teams wanted credit for code complete in Jira to demonstrate a predictable velocity. QA wanted credit for the test complete in Jira to demonstrate a continuous flow. Jira Release Managers wanted credit in Jira for integration activities before deploying to production. Operations wanted credit in Jira Software for the production deployment. As you can imagine, this was relatively messy in Jira and tying work from code complete through managing the release in Jira to Production was excruciating.

While Done may be clearer to your organization, "Release" may not be as clear. Different parts of the organization will have different definitions of Release. For a team, "Release" may mean the code has been deployed to a QA environment. For Operations, "Release" may mean deployment to Production. In the example above, "Done" and "Release" meant the same thing among the teams, QA, and Jira Release Management, but not Operations. Nor did it mean the same thing across the organization. Without clarity across the organization, tracking and managing Releases in Jira Software becomes nearly impossible. Clearly defining "Done" and clearly defining "Release" across the organization can drive organizational alignment. Once you understand these two concepts, you can manage these Jira releases in Atlassian using the following two methods: The Release Issue Type or Bitbucket Pipelines.

Method One: The Release Issue Type

Within your SDLC projects in Jira, create a new Issue Type called, "Release." This lets the organization know that, while code is complete, there are additional items that need to be fostered through the process. These may include documentation, release notes, a hardening sprint, or anything that can foster work from code complete to Production. The additional items can be managed as Sub-Tasks of the Release to understand the scope of work needed to move it through the process.

As with any new Issue Type, the Release in Jira will need a Workflow. The Workflow can be simple, however, we recommend using a Ready for Production Status in the workflow. When integrating Jira with Jira Service Management, the transition to Ready for Production is a perfect time to automate creating a Change Request. Your Operations team can review the change request with a link back to the Jira Release Issue Type.

How do we know which stories and bugs are tied to the Release in Jira? Do we link all the work to the Release Issue Type? No. I mean, you could, but why take the time to do that? Is it really a value-added activity for traceability? Is there another way to tie these things together that could be quicker and easier? The answer: Yes.

Even long-time users of Jira forget about Versions. If used properly, Versions can provide every team the status, progress, and any known issues in a single view in the Release Hub. This is true for all development activities AND the Release issue. By adding the Fix Version of the intended Release, every part of the organization can see the progress of the Release. Because JQL supports Versions, all items tied to a Fix Version can be displayed in other places such as a Dashboard or a Confluence page. With a little up-front discipline during backlog refinement, or sprint planning, or even big room planning, managing a release in Jira is as simple as adding a Fix Version to the work as well as the Release issue.

When managing Releases in Jira, once the Release issue has been deployed to Production, always go back and release the Version in Jira. Anything that is not in a "Done" status category can either move to the next Version or be removed from any Version entirely.

What if a story or bug spans multiple Releases? There is still only one Release issue per Version. However, I would also challenge you to take a look (again) at your definition of Done versus your definition of Release. Are you actually completing the work or are you pushing it forward again and again because there's a problem? In the next backlog refinement meeting and/or retrospective, ask why this continues to happen. Really dig in and understand whether the work needs to be moved to an Epic, de-prioritized, completed in the next sprint, or abandoned altogether.

Method Two: Bitbucket Pipelines

Using Bitbucket Pipelines still requires your organization to have a conversation defining "Done" and "Release". However, the entities that support these definitions are different when integrating Jira and Bitbucket Pipelines. The Jira Release is managed through the Pipeline and requires little human intervention. Instead, we work with a series of Workflow Triggers and automated deployments to determine where the Release is in its process.

You still need to create a Version in Jira. You still need good discipline during backlog refinement and sprint planning to ensure work is tied to the correct Version. You may also choose to halt the automation just before deployment to Production based on your Change Management processes. Clarify the process before implementing it in Atlassian.

After your Version is created and work is tagged with the Version, add Triggers to your development workflows. For example, you can automate a transition from Open to In Progress based on the creation of a Branch in Bitbucket. You can also automate a transition to Closed or Done once a Pull Request is merged. Triggers in Jira Workflows keep people focused on the work instead of Jira. But where Bitbucket Pipelines really shine is everything that happens after code is merged. Separate Pipelines can be created per environment. For example, if you need to manually deploy to production, a Pipeline can automate the process through build and deploy to a staging environment after it passes all checks. Commits, build, and deploy information is visible in the Development Panel of the individual story or bug. You can even quickly understand failures and receive additional information by clicking on the failure. For a specific Version, as long as work is tagged, you can aggregate the overall health of the Release in the Release Hub by viewing the Version. Status, success, warnings, and errors are available in a central location. If everything looks good, simply click a button and deploy to Production. Alternatively, if the staging deployment is successful, automate the production deployment in the Pipeline as well.

Which Release Management in Jira is right for you?

At Praecipio Consulting, we believe the answer is: "It depends." Regulatory compliance, risk tolerance, product uptime requirements, etc., may dictate which Jira Release Management method is right for your organization. And, to boot, the answer can be different for different parts of the organization. However, the critical first step to implementing release management using Atlassian Jira is to have a conversation. Are your definitions of "Done" and "Release" at odds with one another? What do they mean from a process perspective? Is there room for improvement in those definitions? If you can answer those questions you’re well on your way to having effective release management in Jira.

We here at Praecipio Consulting have extensive experience with both Jira Release Management best practices and the Atlassian suite of products, which we are happy to share with you to help you achieve more effective release management with Jira.

DIY or DIE!

For those of you watching from home, I have been on a home improvement journey for quite some time. Applying an Agile mindset to home improvement (or really anything I do) is one of my passions. Even at my most recent Women in Agile meeting, we discussed applying Agile concepts to daily life and feeding these back into building a great resumé. One of the principles of the Agile Manifesto reads: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. We all know this applies to Agile development practices, but it also applies to IT Service Management. Specifically, Incident and Problem Management. For me, it applies to my recent home improvement adventure. 

Strong fences make great neighbors

My neighbor and I spent the better part of a Saturday fixing our mutual fence. You see, I have two dogs: Leonard and Howard.

Both are rescues. Leonard is eight and was "free to a good home" while Howard is four and was adopted from my county's animal shelter. Both dogs have been with us since their puppyhood and, as any dog owner will say, they are the BEST. DOGS. EVER. Except when they're not. This was not the first time my neighbor and I had to work on the fence. Observe one of the troublemakers in his natural habitat. 

This epic saga started in May of last year. I would diligently fix loose boards, prop items against the fence to "patch" holes, and monitor their outdoor activity while I was awake (awake being the key word here: 3am barking and fence-patching sessions are no fun). I supplied my neighbor with fence planks because, well, they're my dogs. We fixed the section above and let the others lapse until a series of shenanigans prompted my neighbor and I to spend our Saturday replacing three additional sections. My neighbor and I became united in making sure my two didn't escape. While my neighbor "doesn't care" that my dogs are in his yard, my (very good) boys take the opportunity to break out of his fence and wander the neighborhood. Howard usually comes back, but Leonard meanders through the streets, swims in pools or the lake, and generally causes mayhem until I can coax him in my car to come home. 

Not in my back yard...

Before this latest patch, I was determined to find the root cause. Previous to May of last year, this was not a problem. My puppers would frolic in the backyard and simply bark at other dogs in the neighborhood as they walked by. I made sure they were let out several times per day to make sure they were relieved in addition to daily walks. While I was traveling, they were also well-taken care of and monitored. What changed? 

Root cause analysis is, simply put, problem solving. While it is widely used in sciences and engineering, it is also a key element of IT Service Management Incident and Problem Management. When reacting to an incident, the team must restore functionality as quickly as possible. Upon resolution, root cause analysis helps us understand why. It then prompts us to ask, "Is there an action I can take to prevent this from happening again?" Incident Management leads to Problem management and through root cause analysis, we can move from a reactive organization to a proactive organization. 

Of the many techniques of root cause analysis, my favorite is the "Five Whys". It is the simplest technique: ask why until you've identified the root cause. Not like a petulant child, however. Asking the first why should be easy, then continuing to ask well-curated questions based on the previous answer helps you determine the root cause. I applied this to my situation: 

• Why do I have to replace parts of the fence? 
  Because the dogs are chewing through the fence.
• Why are the dogs chewing through the fence?
  Because they can access the backyard whenever they need.
• Why can the dogs access the backyard whenever they need?
  Because we installed a dog door.

HA! I found it. The root cause. And it didn't even take me all five whys. 

Any root cause analysis technique does not stand alone. There exists a plethora of other techniques. Pareto charts determine that 80 percent of your problems are derived from 20 percent of the causes. An Ishikawa (fishbone) diagram looks at measurement, materials, methods, machines, management, and mother nature. Scatter plots let us look at correlation and causation. Was the dog door the root cause? The existence of a dog door doesn't change the behavior of my boys. Having access to the backyard doesn't make them chew through the fence planks. Did we ask enough questions to actually identify the root cause? Did I also consider a Pareto analysis, an Ishikawa diagram, or a scatter graph to understand why I was constantly chasing my boys through the neighborhood? 

I stopped at three whys: "I have a dog door."

What happens if I keep asking why? 

• Why did we install a dog door? 
  Because Howard wasn't fully potty trained. 
• Why wasn't Howard fully potty trained? 
  Because I didn't take the necessary time to train him. 

AHA! My Ishikawa diagram identified "management" as the issue. My Pareto identified the 80 percent as my time to train my puppers. My scatter plot showed the amount of time spent correlated to the amount of dog-induced shenanigans. I would add these to the post, but won't because...reasons. More importantly, I simply kept asking, "Why?" until I identified the root cause. 

Actions speak louder than words

Now that I have a root cause, what is it that I can do to prevent this issue from recurring? When looking at Incident and Problem Management, Atlassian products such Opsgenie and Statuspage can ingest, aggregate, correlate, and trigger the creation of Jira Service Management issues. With Confluence, we can create specific root cause analysis templates to be shared with our customers and stakeholders. However, it's up to our techniques and processes to help us determine the actions we need to take going forward. 

For me and my puppers, it's simple. 

1. Take at least 30 minutes out of my day for dedicated doggie exercise
2. Reinforce good behavior while in the yard
3. Lock the dog door overnight (no more 3AM "let me sing you the song of my people" moments)
4. Finish replacing the aged planks on the fence

By taking these actions based on my root cause analysis, I should have this solved quickly with redundancies built in. My puppers will be safer and happier, I will have a beautiful new feature of my home, and the three of us will have less stress day-to-day. Using root cause analysis techniques, and Agile mindset, and drawing from IT Problem Management, I can easily solve this problem and any additional ones around my home.

BRB, gotta run and get some more fence planks.

In October 2020, Atlassian announced End-of-Life for their Server products coming on February 2, 2024. With Atlassian's continued investment in both their Cloud and Data Center hosting options, many organizations are making the switch to Atlassian Cloud. Atlassian is continuing to invest in and expand capabilities in Cloud to support even the largest customers. 

With the announcement, you and your organization have decided to either migrate to Atlassian Cloud or deploy an Atlassian Cloud instance and migrate teams as they're ready. But which Atlassian Cloud tier is best for you? 

The Four Tiers

Most Atlassian Cloud products* are available in four tiers: 

• Free
• Standard
• Premium
• Enterprise

*Trello and Bitbucket are the exception. More information on these two products later. 

Standard, Premium, and Enterprise tiers can be licensed either monthly or annually and each product can be licensed individually as well. For example, you can license Jira Software Standard monthly at 50 users and Confluence Premium annually at 200 Users. As always, Atlassian provides you the flexibility for your unique implementation. Even if you don't make the right choice the first time, you can always upgrade to Standard, Premium, or Enterprise in addition to adding licenses as needed. Let's take a closer look at each tier. 

The Free Atlassian Cloud Tier

The Free tier is a great way to get started with the Atlassian Cloud products. If you've never used Jira Core, Jira Software, or Confluence, pick a pilot team of less than 10 people (including Administrators). This team can act as your test team to both configure and use the products. You can also add other products such as Bitbucket and Jira Service Management. Bitbucket is free for up to five (5) users and Jira Service Management is free up to three (3) agents. The Free tier also includes limited storage for attachments, out-of-the-box reporting, and (depending on the product) automation. And of course, you can extend functionality through the Atlassian Marketplace. Support for the products is offered via the Atlassian Community: a robust Q&A platform that references Atlassian's product documentation, Marketplace vendor documentation, and general answers to just about every question you can think of about the products. 

Don't forget about Trello! Trello is another way for a team to organize and collaborate on work. Trello is free for up to 10 boards. There is no user count limit. Trello allows teams to create Lists and create and manage Cards to represent their work. The team can create as many Lists and Cards as they'd like on a single board. And with up to 10 free boards, the team can manage multiple work efforts on separate boards based on categories or work types. 

As an example, I have a Free Atlassian Cloud Jira Software and Confluence instance for my household which consists of my parents, a few close friends, and myself. This allows us to plan trips and vacations with one another (all Jira issues are sitting in an On Hold status currently), share pictures, links to events and lodging, and organize decisions as needed. I also have a Trello board that helps me organize my longer-term home improvement projects. Since these items are longer lived without any specific due date, I prefer Trello's flexibility such as creating lists, updating labels, and reprioritizing based on my monthly and annual budgets. 

Standard Versus Premium (and Enterprise)

Each of the three tiers (Standard, Premium, and Enterprise) can accommodate up to 10,000 licensed users. The key difference between the Standard and Premium tiers in Atlassian Cloud is added functionality. While there are a few differences between Premium and Enterprise, they only apply to specific requirements such as data residency, uptime, the inclusion of Atlassian Access, and billing. Let's focus on the key differences between the Standard and Premium tiers. 

First, storage is limited in the Standard tier to 250GB per product. If your organization attaches to or stores a significant number of files in issues or pages, you may hit this limit faster than anticipated. Second, support is offered during local business hours. That usually means 9am to 5pm in your timezone. And third, Standard has no uptime guarantee. If your organization requires 99.9 or 99.95% uptime, you should look at Premium or Enterprise, respectively. 

The Premium tiers for each product offer a significant amount of added functionality with more on the way. For example, Jira Software Premium adds Advanced Roadmaps for Jira and both Jira Software Premium and Confluence Premium allow for native archiving. For larger instances, archiving is an administrative boon as older data is removed from the search index and can only be accessed by a designated group. In addition, the Premium tiers add a significant amount of administration logging and management, adds unlimited storage, and adds 24/7 Premium Support. 

Bitbucket Standard offers unlimited end users, an increase from 5 on the Free tier. The Bitbucket Standard tier also increases Git Large File Storage to 5GB (from 1GB at the Free tier) and Build Minutes increase from 50/month to 2500/month. Bitbucket Premium, however, provides even more Git Large File Storage (up to 10GB), increases build minutes to 3500/month, and adds enforced merge checks and deployment permissions. As of the writing of this document, there is no Enterprise tier for Bitbucket. 

Trello has a slight difference in the names of their tiers. Instead of Standard, Premium, and Enterprise, Trello uses Business Class and Enterprise. As you would expect, Trello Business Class adds unlimited Boards, significant customization opportunities (i.e. backgrounds, custom fields, and templates), and automation runs (though capped at up to 6000 per month). Trello Enterprise includes all the same features as Business Class, increases automation runs to unlimited, and extends administrative capabilities such as organization-wide permissions and enhanced restrictions for things like attachments. 

What should I be asking when trying to decide which one is best for me? 

<Insert typical consultant answer here> It depends! Atlassian has provided transparent pricing for each of their products and each tier of each product as well. Atlassian has also included a handy comparison table for each product for you to quickly see what is included in the tiers. Here are a few additional things to be asking yourself as you start your journey to Cloud. 

• How many people will need to work in the products? 
• How are those users managed currently?
• Do you have any data residency restrictions (e.g. GDPR)? 
• If you're currently using the Atlassian products, how large are the instances?
• If you're currently using the Atlassian products, which Apps are you using?

While not an exhaustive list, these questions may help guide you in looking for the right products at the right tier. Of course, Praecipio Consulting has extensive experience with the Atlassian Cloud products and we're here to help! Reach out to us today to let us help you narrow your options. 

"How many hours are in a Story Point? Pink. Because penguins don't like ice cream." -Amanda Babb in every conversation about hours and story points. 

While I use this example as a cheeky way to say the two methods of estimation (hours and story points) don't coincide, the reality, of course, is much more complex. Business and product teams typically think in terms of dates and schedules. Development and operations teams typically think in terms of level of effort. That's not to say story points and dates do not nor will ever coincide, it's a matter of how to speak each other's language. 

What is a Story Point?

Our Dragon of the West, Christopher Pepe, explained it well:  humans are terrible at numbers. That's why we have so many ways to express things without using numbers. For example, I have Big Dog (Leonard) and Tiny Dog (Howard). Tiny is small in comparison to Big Dog. However, at 50 pounds, he's not small compared to, say, a Chihuahua. This is what we call relative estimation in the agile world. This thing is larger or more complex than the other thing over there: it will take a larger level of effort to complete. 

Computers, on the other hand, are wonderful at numbers. It's part of the reason we invented them. In Jira Software, a story point is simply the numerical expression of a relative estimate. When we need to understand the level of effort of more than one thing, we aggregate the relative estimate into a total level of effort. This is known as the commit in a velocity chart. As we complete work, we burn down the level of effort until we understand what's left. At the end of a sprint, we determine whether we met our commit or not. The completion of the work over several sprints determines our velocity. From there, we can reasonably predict the level of effort we can complete during a sprint. 

Why can't a team estimate in hours? 

It's not a matter of can't. At Praecipio Consulting, we've seen many teams succeed well in estimating their level of effort in hours. However, this involved a significant effort to run time studies on routine tasks for the team. In a time study, an outside party will watch a person do a task and time it. Then watch them do it again...and again...and again. Then, the outside party watches another person perform the same task several times. The outside observer will continue with this until they feel they have sufficient data to make a reasonable assumption (read: average) of the time it takes to complete said task. Rinse and repeat for all tasks all personnel complete in a day and through out the week. 

Estimating in hours works well in repetitive work environments. The same tasks must be completed the same (or similarly enough) throughout the day and week. However, when we're thinking about software development, we all know this is rarely the case. What may seem like a simple feature request can become a significant effort when looking at how the new feature interacts with the rest of the services, modules, or products. Yes, we've done something similar before and it took four hours. But what has changed since the last time we implemented something similar? What else have we deployed? Did we change our methods? Are we integrating this with another system? Have the APIs been updated or changed? How many releases have been performed since the last time we did this? 

The shoulds and shouldn'ts of tracking time in Scrum

Why are teams being asked to track time when they estimate and understand level of effort in story points? In a word, Money. Under complex financial and regulatory practices, most businesses report quarterly earnings to regulatory bodies and markets. The best way a business has to gather and report this information is through complex financial systems that aggregate data from inputs across the organization. One of the more critical inputs? Time tracking. So how should we and shouldn't we track time in a scrum team? 

• You should establish the minimum time guideline such as 15-minute or 30-minute increments
• You should not expect accuracy down to the minute for a given task
• You should expect the team(s) to continue to estimate their level of effort in story points
• You should not make the team switch to hours to estimate their level of effort
• You should centralize where the team should track time
• You should not expect the user to log in to multiple tools to track time
• You should download our Lean Budgets White Paper which details different ways of managing the data and provides a solution in Jira Align
• You should not expect to implement a fundamental change in financial tracking and reporting across your organization without help

At Praecipio Consulting, we have implemented several solutions to this problem across industries and with all sizes of organizations. For help regarding how your teams can balance time tracking, scrum, and financial reporting, feel free to reach out to us! 

As an Agile evangelist and a Digital Transformation-ist, I am asked this question from time to time. My first thought is, "Of course you're Agile...you just don't know it yet," but before I can actually answer that question, I have to understand the process. Every organization and agency in the world takes something, does something with it, and produces an end result. It's the process that is key for you and your organization to understand before implementing the Atlassian tools and specifically, Advanced Roadmaps for Jira (formerly known as Portfolio for Jira). 

At Praecipio Consulting, we call ourselves a bunch of process nerds that just happen to use the Atlassian tools to facilitate work. Think about making a pot of coffee: there are specific steps you have to take in a specific order to be successful. Starting the coffee pot before adding water and coffee doesn't work. Adding water and starting the coffee pot (without coffee) doesn't work either. There's a specific process that you need to follow to produce a pot of coffee. 

When it comes to work, what's the first step? How does the organization take in work? For those running traditional models, you may know this as Requirements. We have an idea that we'd like to propose, gather the requirements, and define the project scope. We then move to Design: expected function and architecture, and then to Implementation: actually putting the requirements into place in a product. In each of those phases, Advanced Roadmaps for Jira can help! 

What is Advanced Roadmaps for Jira? 

Advanced Roadmaps for Jira is a planning and roadmapping tool from Atlassian. It was first released in 2015 and has since developed into a powerful visualization tool for small-to-medium-sized organizations. With Atlassian's dedication to maintaining framework flexibility, it has evolved to become the tool of choice for many organizations, regardless of their self-proclamation. By supporting three estimation statistics (Days, Hours, and Story Points), Advanced Roadmaps for Jira can provide you with the best chance of success for understanding cross-team and organizational dependencies and answering the most important question, "When will this be done?" Purpose-built for Jira Software, Advanced Roadmaps for Jira supports mixed methodologies as well as framework-specific organizations. Add in the concept of multi-layer hierarchies, and you've got yourself a Work Breakdown Structure (WBS) as well as the ability to automatically schedule timelines based on Team capacity or velocity. 

Advanced Roadmaps for Jira adheres to the concept of the Iron Triangle. What is the scope? What is the timeline? Who are the resources (people) involved? Based on the estimated scope of work, the timeline in which I need to get it done by, and the people I have to do it with, will it be available on time? Simply choose the estimation statistic to calculate a schedule and you're off! Well, almost...

Scope: Where is the work being tracked in Jira? 

When creating a Plan in Advanced Roadmaps for Jira, the first thing to understand is the source. After establishing your hierarchy, determine where these Jira Issues exist. Where is work being performed in Jira? Is it in a specific Jira Project? Or perhaps a Kanban board for process visualization? Or across multiple projects? These are the sources for creating a Plan. You can use Jira Projects, Boards, or Filters as the source for a Plan. You can also use any combination thereof. However, aim for simplicity: use a Jira Project or a Board when you are able to instead of a complicated Filter as a source. 

We recommend using Filters as a source only when you need to manage stage-gates in your process. Using the example above, If the Statuses in your Jira Workflow are Requirements, Design, and Implementation, consider creating a filter that excludes Requirements. Just because it's a good idea, doesn't mean we will pursue it past the Requirements stage. In a Plan, we only want to see those things that made it through the stage-gate into Design. It's in the Design stage we will determine if or when we can get it done based on the timeline and people before moving into Implementation. We are not ready to Plan an effort until we've passed Requirements. 

Resources (Teams and Team Members): Who is doing the work in Jira?

While it's a bit chicken-egg, determining who is doing the work is critical to determining scope. In a Plan, we connect Teams and Team Members to the Sources in the Plan. This eliminates the need for clicking or typing or trying to assign a piece of work to the correct Team in a Plan. By connecting these, Advanced Roadmaps for Jira will determine the scope for the Teams and Team Members based on the source of the Plan. You also have the ability to tie multiple Teams to a single source. As an example, if you have two Teams managing their work in a single Jira Project, you can use the Project as a source for both Teams. By adding Team Members to the Teams, you can guarantee assigned work will be directed to the correct Team. However, unassigned work will be divvied up based on the next Team Member's availability. We recommend creating a single source per Team if both Teams cannot be assigned each others' work. 

Moreover, by adding Team Members to your Teams, you can determine the hourly capacity of each member. We see this most frequently used when specific job functions are split across Teams (e.g. QA or Design). By default, Advanced Roadmaps for Jira calculates 100% capacity at 40 hours per Team Member. If you need to split capacity across Teams, simply adjust the Team Member's capacity to 20 hours (50%) on one Team and 20 hours (50%) on the other Team. By using the Auto Schedule function in a Plan, you can then recalculate the timeline based on the change in capacity. 

Time: When will it be done?

This is where the power of Advanced Roadmaps for Jira truly shines. By using Releases (aka Versions), the Plan can calculate your probability of completing the effort on time. The Plan can also calculate when an effort will be complete based on Scope and Teams. For example, if I estimate my effort will take 4000 hours and the Team has a capacity of 200 hours, it will take 20 weeks to complete the effort. If my Release finish date is in 10 weeks, I will be off track by 10 weeks. The Plan will highlight this in red. 

Don't think of Releases as traditional "software releases". Instead, these are milestone dates for a specific Jira Project or across multiple Jira Projects. They can be calendar quarters, fiscal quarters, or even a specific date-driven event. By designating the Finish Date of a Release, you are determining the amount of time the organization has to complete a specific (or the entire) scope of work. 

Dependencies and Scenarios

Critical Path is a common concept in a traditional WBS. These larger milestone issues drive the entire schedule. If one moves, the rest move as well. In Advanced Roadmaps for Jira, we can manage this via Dependencies. By linking issues together, the Plan will schedule work using a finish-to-start dependency. Issue 1 must be complete before Issue 2 can start. Moreover, since items at the lower levels of the WBS drive the size and duration of the critical path, you can visualize a schedule slip based on the progress of the lower levels. 

Not sure you're ready to commit to a specific Plan? When trying to understand the "What if?" in each Plan, you can enable Scenarios. The Initial Scenario (default name) is used to understand current state: what the are Teams currently working on, the progress, schedule, and release dates. Creating additional Scenarios allows you to Plan for best-case or worst-case scenarios. What happens if I add capacity to the current scope of work? Will I be more likely to hit my Release (aka milestone) dates? By adding a Team to a Scenario (thus increasing capacity), you can Auto Schedule just that Scenario to determine if there is any impact to the overall schedule and any milestone dates. If you like what you see, you can update Jira Software from that specific Scenario and any other Scenarios will update based on the underlying Jira data. 

Want to know more? 

As an Atlassian Platinum Enterprise Solution Partner, Praecipio Consulting can help you determine the best way to leverage Advanced Roadmaps for Jira to support your intake, planning, and execution processes so that your organization can become more Agile. We have extensive experience in the entire Atlassian product suite and implementing Agile frameworks that provide a great foundation for your organization or agency. 

Are You Ready to Scale Agile? 

You are an Agile evangelist. You have championed the shift to Agile at your organization and have coached several teams successfully. Your organization is delivering quality product faster to your internal and external customers. But there's still a struggle to coordinate across different parts of the organization. And you get pulled into meeting after meeting to coordinate across teams. As a result, your most successful teams are expressing frustration with each other and, and now, quality has slipped. Something has to change. 

You've heard about scaling Agile. You may even have an idea of some of the well-known frameworks, such as SAFe, LeSS, Scrum@Scale, etc. But are you ready? Is your organization ready to scale Agile? 

Organizational Readiness

While this is not an exhaustive list, ask yourself and your organization these questions to assess your readiness to scale Agile. 

• Which framework is best for your organization?
• Do you have management and executive buy-in? 
• Do you have funding for external training and certification?
• Can you group teams together to support strategic initiatives?
• Can you identify your change agents and champions?
• Can you identify a set of teams to pilot the change?
• How much time are you willing to commit to the change?
• How much time do you have to commit to the change? 
• How much time are you willing to commit to continuous learning? 

Iterate Your Framework Implementation

Just like the scaled Agile frameworks themselves, you approach their implementation iteratively. One of our clients chose and implemented SAFe for a single program and scaled iteratively. They started with one Agile Release Train and in three years scaled to four Agile Release Trains with the intention to launch an additional train before the end of the year. They also reorganized the Trains once they realized they were no longer organized around value and instead were structured in a traditional resource-management way. 

The implementation of SAFe within this client's organization, while it had a specific start date, was implemented iteratively and over time. It also took the backing of management and executives and a devoted set of change agents willing to take the steps for scale.

We here at Praecipio Consulting have assisted our clients in their journeys to scale Agile. Let us know how we can help you take your first step. 

As organizations continue to scale Agile practices, our team at Praecipio Consulting is frequently asked which Atlassian product will best support the effort. Principal Consultant, Brian Nye, put together a great webinar describing the differences between Advanced Roadmaps for Jira (formerly known as Portfolio for Jira) and Jira Align. As Praecipio Consulting has expanded our Jira Align practice, we'd like to take a moment to compare and contrast these products to help guide you in making the right decision for your organization. 

Your Agile and Digital Transformation Journey

Your organization can't talk about your Agile transformation without talking about your digital transformation and vice versa. After all, the Atlassian products are meant to support Agile frameworks as well as your digital transformation. Many organizations have embraced remote work as a result of the global pandemic and have fundamentally shifted toward online planning, road mapping, and execution management. 

Your organization may also use non-Atlassian applications to manage planning and road mapping. You've chosen to integrate these products with Atlassian for execution management. While this may be a great solution in the short term, I challenge this as a long-term solution. Many of the frameworks guiding agile-at-scale exist because we're trying to bring strategic planning closer to actual execution and back again. Ask your organization the hard question: does maintaining these integrations follow the organization's digital technology vision for the future? 

Advanced Roadmaps for Jira (formerly Portfolio for Jira)

Available as an App for Data Center/Server Deployments and packaged with Jira Software Cloud Premium, Advanced Roadmaps for Jira (Advanced Roadmaps) is a great way to bridge the gap for small- to medium-sized organizations. If you currently have fewer than 500 agile team members executing their work in Jira Software, Advanced Roadmaps for Jira can provide visibility within and across teams. First, define the hierarchy above the Jira Software Epic. We use Initiative most frequently when deploying this for customers because of the reference documentation from Atlassian. However, you can choose whichever naming convention you'd like as long as there is a corresponding Issue Type. For example, create an "Initiative" Issue Type and link it to a Hierarchy level in Advanced Roadmaps called "Initiative." We also strongly recommend the Initiative Issue Type live in a separate Jira Project from all other execution work. This helps your Agile teams focus on the current backlog of work while the Initiative moves through its own review, decision, and backlog refinement process. 

Creating a Plan is as simple as defining your source data (Jira Projects, Boards, or Filters), tying the sources to Teams, and choosing Releases from your source data. Honoring the Iron Triangle of project and program management, you may either choose to have the Plan dictate your schedule or, when planning for the next business quarter, you may choose to drag and drop the Gantt-style bars to schedule work. There is also an option to blend the calculations. Meaning, if a Sprint already exists and is pre-filled, let the Scrum Board be the source of truth. Have the Plan calculate any Empty Sprints going forward. The same is true for Releases and Teams: the Plan can auto-schedule a Team or a Release based on the relative rank of the backlog in the Plan. 

If you're looking to understand the impact of shifting priorities, you can enable Scenarios in a Plan. This will allow you to pull the source data from Jira Software and blend it with additional planning while maintaining the current execution schedule. You can add new Initiatives, Epics, and Stories, as well as adjust Release Dates, and observe the impact of adding, removing, or reassigning Teams to work. If you have the Server or Data Center App, you can group Plans together into a Program to understand the overall health of multiple Plans and Releases in a single view. 

Jira Align

As its name implies, Jira Align brings strategic planning and execution together in a single product. Pulling execution data from Jira Software and blending it with Agile-at-scale frameworks, Jira Align ties your strategic vision to tangible work and is best suited for organizations with more than 500 Agile team members executing their work in Jira Software. Instead of trying to define a hierarchy, Jira Align provides a pre-set hierarchy with flexible language. Whether you're running SAFe, LeSS, Scrum@Scale, or your own model, Jira Align's seamless integration with Jira Software provides visibility across multiple Portfolios and Programs. 

Jira Align comes in three deployment options: multi-tenant Cloud, single-tenant Cloud, and on-premise. While we recognize the allure of an on-premise solution, Praecipio Consulting recommends either the multi-tenant or single-tenant Cloud deployment. This provides the robust functionality of the product without the additional IT infrastructure management as well as managing routine maintenance such as upgrades. Jira Align also comes in two licensing models, Standard and Enterprise, billed monthly per user. Standard provides your organization the ability to run Programs (also known as teams of teams) whereas Enterprise adds the Lean Portfolio Management and financials into the mix. In addition, each Jira Align seat comes with four Jira, Trello, or integrated users. Another key difference between the two license levels is integration. With Standard, you can integrate a single instance of Jira Software with Jira Align. This is perfect for the organization that is large enough but lacks maturity in their Agile-at-scale framework. Enterprise provides unlimited connectors, which in the case of some of our clients, allows them to avoid the pain of merging multiple instances of Jira Software before deploying Jira Align. 

The Jira Software Epic is the lynchpin of the integration. Teams will still work with Epics, Stories, and Sub-Tasks within Jira Software whereas Product Managers, Release Train Engineers, Portfolio Managers, and Executives work within Jira Align. The robust permissions within Jira Align also focus the right role in the right data. A Program Manager may care about the execution of the program, whereas the executive wants to understand how you're tracking to the annual corporate strategy. By aggregating and rolling data upward, Jira Align provides health and status monitoring of quarterly, yearly, and long-term goals. With over 180 out-of-the box reports, every role at every level can access the right information at the right time to ensure your organization's success. Jira Align also has Enterprise Insights, an optional App, to take business intelligence to the next level. 

Which one is right for my organization? 

The first questions to answer while you're evaluating either tool are around Agile transformation maturity, digital transformation maturity, and user discipline both across and vertically in the organization. Because both options rely on teams to perform their execution work consistently and with good data integrity, either product can be a blessing or a curse. 

• How long have your Agile teams been executing within an agile framework? 
• How long have your Agile teams been executing within Jira Software? 
• How consistent are your teams across the organization? 
• Do your teams and your business understand one another and communicate well? 
• How well has your Jira Software instance been governed since it was deployed?
• How much chaff do you have in Jira Software? 

While this is not an exhaustive list, implementing either Advanced Roadmaps for Jira or Jira Align requires you to ask tough questions of your organization. Praecipio Consulting can not only help you assess your current state, but we can also provide guidance and recommendations to accelerate your digital transformation. If you are ready to take the next step in your digital transformation and Agile journeys, let's chat!

NOTE: Jira next-gen projects are now named team-managed projects, although all the valuable features that have made them an indispensable tool for managing your team's work for years remain the same.

Atlassian has always held the concept of the team in high regard. As you may know, even their stock ticker is TEAM. And with many organizations pushing to Atlassian Cloud from their Server or Data Center solutions, it's no wonder Atlassian is removing barriers to entry for first-time users and admins. Whether you choose Standard or Premium, Jira Software adds the ability to create next-gen projects.

What is a next-gen project? 

Jira Software next-gen projects are a simple and flexible way to get your teams working. With some limited delegated administration, next-gen projects are created using a pre-defined template (Kanban or Scrum). These projects also come with three pre-defined roles: Administrator, Member, and Viewer.

• Administrator: Updates project settings and can add other Administrators
• Member: Can perform most functions such as create, edit, assign, and transition issues
• Viewer: Can view and comment only

By default, if a user is added to the Jira Cloud site and provided access to Jira Software, they automatically become a member of every next-gen project (also known as Open). However, a next-gen admin can change the settings to be either Limited or Private. Limited puts all users of Jira software into the Viewer role and Private requires the admin to add a user to perform actions in the project. In addition, setting the project to Private hides the project from any search results. 

Each next-gen project operates similarly to a Classic Software project. You get either a Kanban or Scrum Board based on your project template as well as the reports you've come to know and love from the Server and Data Center products. One key difference is the addition of a Roadmap. Each next-gen project and board comes with a Roadmap. This allows teams to track start and end dates of the epics and better communicate with their product owners and stakeholders. 

The benefits of a next-gen project

Next-gen projects are flexible and delegate administration to the Administrators. This means the Administrator can create new Issue Types and Workflows, add unique fields, assign access to individuals or groups, and can enable or disable specific agile features such as enabling backlogs. This provides the ultimate flexibility for newly formed agile teams to work out their processes and data needs while performing their daily work. Let's take a closer look at each of these elements. 

Issue Types can be created on the fly at any time. As an Administrator, you can add up to 30 unique issue types to your next-gen project. By default, next-gen projects come with Epics, Stories, Bugs, Tasks, and Subtasks. If you remember, these are arranged in a loose hierarchy with Epics at the top; Stories, Bugs, and Tasks in the middle; and Subtasks on the bottom. Currently, any additional issue types will be added at the same level as Stories, Bugs and Tasks. If you'd like to add your own Subtasks or parent issues, feel free to submit feedback to Atlassian. 

Workflows are configured directly on your Board. Simply add a column to add a status to your workflow. That's it. You may also add rules such as assigning an issue or updating a field. Other Marketplace Apps can add automation triggers and the like to next-gen projects as well. 

Administrators can also add Custom Fields for your project. While Jira already comes with a robust set of Jira-created fields, you may choose to add checkboxes, people fields, numbers, dates, dropdowns and more. You can even change the order of the fields on the issue view to put the most important information at the top. 

Notifications on certain events can also be tuned to suit the team's need. For those already familiar with notifications, these events include: Issue Created, Issue Updated, Issue Assigned, Issue Deleted, etc. In a next-gen project, you can notify All Watchers, Current Assignee, Current User, Reporter, or a Project Role. Simply select the event and the people you'd like to notify, and Jira will take care of the rest. 

Last, but not least, there are nine separate Board features you may choose to enable for your next-gen project. This includes things like the Roadmap, Reports, Backlogs for Kanban, and more. 

There's no doubt that next-gen projects provide your team the ultimate flexibility in managing their work. With easily navigable menus and a simplified Administration interface, next-gen projects can be great for you and your team. 

The disadvantages of a next-gen project

One of the things we love about the Atlassian products is that they are super flexible and you can do pretty much anything you'd like with them. One of the things we hate about the Atlassian products is that they are super flexible and you can do pretty much anything you'd like with them. The same is true of next-gen projects. With ultimate flexibility and delegated administration, it becomes difficult to aggregate data across multiple projects. As a product manager, project manager, Release Train Engineer, or other person over several teams, you may find next-gen projects frustrating. 

Because the configuration of a next-gen project is unique to the individual project, gathering a status update is difficult. Not impossible, but you need a solid working knowledge of Jira Query Language (JQL) and good discipline from your teams to ensure they're transitioning tickets through the workflow. Creating custom Filters and Dashboards is your only way to aggregate data across projects. In addition, since each team can create their own custom fields, you risk data bloat. For example, one team may create a field called Bug Type using a dropdown and another may create Bug Type using checkboxes. While both are correct, to understand where Bugs are located, you have to add both fields to your filter. And the values may be unique per project as well. 

Work can only be estimated in Story Points, regardless if your project is Kanban or Scrum. This is also regardless of Issue Type. If you enable estimation on either a Scrum or Kanban next-gen project, every piece of work should be estimated and estimated in Story Points. Tasks, Bugs, and Stories all need points to establish a consistent velocity for predictability. 

Since there is a single workflow for all Issue Types, the team cannot split processes between types of work. If a Task follows a simplified process (To Do, In Progress, and Done), but a Story needs more detail (Backlog, Selected for Development, In Progress, and Done), the team cannot split these items into two distinct workflows. Every type of work must follow the same path through the board. 

There are additional technical considerations as well for things like Cloud merges (bringing two instances together) and Cloud to Server or Data Center migrations (moving off Atlassian Cloud to an On Premise solution). While these efforts are few and far between, all next-gen projects must be converted to Classic projects before these efforts start. 

Are next-gen projects right for you? 

At Praecipio Consulting, we believe you must use the right tool for the right job, and the same goes for next-gen projects. That’s why our team offers a variety of Product Services to ensure that your team can leverage these tools as effectively as possible to meet your goals. 

Not sure what exactly your team needs? Contact us today and we can talk about what strategy would work best for your specific needs.

Student Diversity is Key for Learning

Over the last two years, I've had the pleasure of partnering with Atlassian University to provide a wide range of training, including in-person courses, virtual courses, and even being the voice of Planning with Portfolio for Jira. If I had to count, I've likely delivered training to close to 1000 students since 2017 as an Atlassian Certified Instructor, but this week was a first – one of my students was blind. 

When teaching an Atlassian University course, we provide students with access to a virtual environment to practice the concepts presented. Each student is also provided soft copies of the slides as well as a lab workbook to guide them step-by-step through the environment. This particular course, Confluence Server Essentials, provides new users the opportunity to learn about the basics of Confluence. Navigation, page creation, blueprint usage, and collaboration features such as @ mentions, comments, and blogs are all covered in the full-day course. 

My blind student had a laptop with accessibility features and used the Jaws Screen Reader to help navigate the different UIs of the applications. He also had a colleague to assist him if needed. As I started the course, he was attentive and eagerly participated in the discussions. However, when it was time for everyone to log in to their environments and start the first set of exercises, I noticed that he was starting to fall behind. 

During the exercises, his assistant had a technical issue with her own laptop and asked if I would step in while she talked to tech support. I sat down and watched as he tried to navigate his screen reader through the Confluence System Dashboard and eventually to the correct Space to continue through the lab. This was my first time working with a screen reader, and I spent quite a bit of time wondering how it chose which parts of the screen to read. However, once we got into a rhythm, I was able to help him navigate to the correct menu. By the end of the time box, we managed to complete two of the four exercises. 

Accessibility in Atlassian Products

Atlassian supports or partially supports accessibility requirements for Jira, Confluence, and Bitbucket Server and Data Center products, in compliance with Section 508 and WCAG 2.0 (AA). At Praecipio Consulting, we developed a custom accessibility app for Jira, at a client's request, to accommodate sighted and non-sighted users. While support and partial support of accessibility are steps in the right direction, I still needed to find a better way to help this student. 

Enter the Atlassian Marketplace. If the functionality doesn't exist in the products themselves, we search the Marketplace for apps to add on to the instance. There are over 2000 apps available for Server, almost 1000 for Cloud, and nearly 700 for Data Center instances of the Atlassian applications, and these apps are generally tagged with additional information to further help you make the right choice. Through a quick search of all compatible apps tagged as Supported, I found two that looked promising: Accessibility for Confluence and Unstoppable for Confluence. Not knowing which one would work best, I tossed a coin. 

Because the Atlassian University lab environments work like a mini Server environment, they function the same as the customer instances of Confluence we work in every day. Following best practices, I wanted to test the installation of the app in a separate environment before installing it for the student. In my Instructor Environment, I found the user with the most administrative rights (as per the lab workbook) and installed the app. A quick check of the documentation told me the additional installation steps needed to activate it. As testing is important as well, I validated functionality myself first, and I was confident this app would provide the student with a better learning experience. 

A Retrospective on the Accessible Experience

Once installed and configured, my student was able to continue forward with the next two labs, including all exercises. Through exercises like creating a blog post, editing a page, and adding attachments, he was starting to understand how Confluence could help him with his daily tasks.

What did we do well?

• Found an accessibility app and installed it
• Walked the student through how to use it
• Provided 1:1 instruction during labs to ensure understanding

What could we have done better? 

• Communicated about the student before class
• Researched screen readers to understand the best one
• Asked the students for a solution

Going forward, I want to identify students with accessibility needs beforehand, so that I can prepare accommodations as needed. While I have thought about this as an instructor before, now that I've had the experience and have learned from it, I am better prepared to provide a better learning experience for all of my students moving forward.

We can all do great things if we communicate ahead of time. If you or your organization have accessibility needs, let us know! We can bring solutions and custom solutions as needed.