UPDATE: Tempo Budgets is now Cost Tracking for Tempo Timesheets in Cloud. Tempo Budgets is still available as a Data Center app. Contact us for more information on the feature differences between Cost Tracking for Tempo Timesheets (Cloud) and Tempo Budgets (Data Center)
Our Senior Consultant Morgan Folsom shared insights from her Agile Project Management client engagements and explained how to seamlessly manage projects and portfolios in one place.
Today we're going to talk about APM (Agile Project Management) with Atlassian and the Tempo suite. Agile Project Management is easy with Atlassian, especially when you pair with the Tempo suite. It allows you to seamlessly manage your projects and portfolios in one place, which is really where your teams are working.
Join us on May 8th for our next webinar. We're gonna be talking all about Atlassian Summit and ask me anything with the Praecipio Consulting partners. Let's do some quick housekeeping: no doubt you'll have some questions, and when you do use the control panel on the side of your screen to ask them. We'll get to your questions as fast as we can. If we can't get to all the questions during the webinar, we'll follow up with answers as soon as possible.
We have hundreds of clients across the United States, ranging from small and medium businesses all the way to the top fortune five. Our clients include the world's largest retailer, the top media company, and the top automotive retailer. This also includes the largest healthcare services company and electronics manufacturer.
Let me first take a moment to tell you about us here at Praecipio Consulting. We're an Atlassian Platinum Solution Partner, and we've been doing this work since 2008. Over 99% of our projects are Atlassian related: this includes work around DevOps, IT Ops, Agile and Scaled Agile. We do pretty much everything there is to do in the Atlassian world, everything from implementation and training to custom development, licenses and upgrades, and managed hosting and services.
Alright that's enough of me talking, now I want to hand it over to one of our rising stars: Senior consultant Morgan Folsom.
Great, thank you so much, my name is Morgan Folsom: I'm the senior consultant here at Praecipio Consulting. I spent much of the last year helping clients extend the Atlassian toolset in order to adapt in an increasingly Agile world, particularly using Atlassian and the Tempo suite.
So that's enough about me, let's get into what you're all here to hear about! Okay, so today I'm gonna start by laying the foundation: I'm gonna talk a little bit about Agile and some Agile Project Management concepts that we're gonna be digging into today. From there I'm gonna jump into some common mistakes, things that we run into pretty commonly; and then once we get into the Tempo suite, which will follow that, we'll walk through some of the ways that Tempo can help you avoid those mistakes, and ways that you can really really do Agile in the Tempo Suite, particularly Agile Project Management. From there we'll wrap up with some time for questions right there at the end.
First we're gonna dig into some high-level Agile and Agile Project Management concepts. I'm not gonna go into too much detail on these, I'm sure many of you are already familiar with the fundamentals here, but I just want to give everybody a refresher and some some context to what we're gonna be talking about today.
Driven by the Agile Manifesto, a set of twelve principles that were defined in 2001, Agile is really just a way for organizations to succeed in uncertain environments. So although initially it was geared toward software development, as agile has matured and grown, we've really been able to see its success when applied to many different departments, which includes Project Management.
What we see here on the screen, I think really gets to the core of it, and why agile isn't only meant for software development teams. Really at its core it's the ability to create and respond to change; so dealing with, succeeding in an uncertain and turbulent environment, that's something no matter what department you're in, I'm sure you've run into that uncertainty, the turbulence, and really tried to figure out how way how to deal with it: that's what Agile Project Management really focuses on.
Similar to how software development teams use Agile and Agile Project Management, we're going to see many of the same fundamental tenants. Right out of the gate, projects are broken down into smaller pieces: more than just major milestones or stage gates, pieces are consumable and manageable. With these smaller pieces, you're able to estimate better, you're able to get a really stronger forecast when things are smaller, easily manageable.
Responsibility for keeping the project on track, reporting on progress, and goal-setting are all distributed to the team. It's not just one Project Manager who is in charge of every tenant of the project; rather you may have someone like a product owner who determines the goals of the project, but ultimately the team members are who are responsible for delivering a solution. The key is to build consistent teams that you trust, that are reliable, predictable, so that as a P.M. you can loosen the reins, increase team buy-in in the end product whatever that may be.
Another key tenant here is the ability to change course: unpredictability is inevitable, right? With Agile Project Management you don't have to wait six months to see if what your building is gonna work, what you're delivering is gonna work, since the work is broken down into fine smaller pieces, you're meeting with the team, communicating regularly, you can see quickly if that bigger picture isn't gonna work.
So the major focus here is increasing predictability. If you know how much work a team can complete over a set period of time, you know who's going to be working on this work consistently, what skills they have: it's much easier to predict things like releases and forecast budgets rather than being given deadlines of dollars and not really having any idea if you're gonna meet them.
So now with a basic understanding of what Agile Project Management looks like, I want to talk about a little bit of what we see: common mistakes, things to avoid, really kind of those red flags when we're working with a team who is trying to be Agile or do Project Management in an Agile way. There are a few things that are right out of the gate red flags that we really can help alleviate.
The idea that all the work isn't laid out at the beginning of a project can be really jarring for traditional waterfall organizations, and the idea that you haven't set a bunch of metrics or a bunch of requirements at the beginning can be a bit scary. That fear is definitely understandable: the key here is that you don't know everything at the beginning of a project! You can try as much as you want to figure out what the risks are, what all of the requirements are. But with Agile there's the acknowledgement that you don't know these things: you can know some of this, you can definitely do your market research, talk to your stakeholders; but requirements change, budgets change, these things happen.
The key here is when you are first setting up your budgets, your project management, is to not tie yourself to one number or to one set of numbers. The encouragement there is to work off of slags and the understanding that you can't predict the future, no matter how good your Project Management chops or tools are. One of the biggest red flags that I see in an organization that's trying to practice Agile Project Management is the insistence on stage gates. Agile Teams should be having regular sprint reviews and demos, which really make your stage gates unnecessary. If there's a continued reliance on high-level approval for every single step in the process, your progress can be slowed or stalled even.
The idea here is that if you try to include these stage gates in your budgets and plans, they're just not necessary. You'll see with, for example if you or your teams are running scrum, that with your regular scrum meetings and ceremonies that stage gate meeting: regularly, quarterly, monthly, whatever that looks like for you, becomes unnecessary. With your sprint demos your stakeholders are included in those demos every other week, maybe every two to four weeks. They're kept in the loop, they know what's going on, if you need to pivot before a stage gate meeting might be scheduled, you can do that and you don't need to wait until the very end to figure out that something that the team has been working on isn't gonna work .
In your current tools you may have it locked down so not everyone can see your project plans: I definitely get this, it it's definitely more comfortable being able to control that visibility and have that lock down. However part of Agile Project Management is ensuring that everyone, the whole team is involved with, not only Project Planning but Project Tracking.
Honestly hiding your budgets not only prevents the team from understanding the bigger picture but it keeps a lot of control, a lot of responsibility, in just a small group of people's hands. Holding on to that control may seem necessary, but trust me it's not.
So with those in mind those common mistakes and red flags, what I want to talk about now is how we can prevent you from falling into those traps. So I'm gonna start with some background on Tempo: what it is and why are we even talking about it today. Tempo helps teams at more than 10,000 companies, small businesses, large scale enterprises, across multiple industries really to collaborate plan schedule resources manage budgets and track time in Jira.
With Tempo, businesses gain better visibility over work efforts, they have the ability to forecast and prevent data silos, and really stay strategically aligned. Tempo has been an Atlassian
ecosystem developer since 2009, and they're one of the largest, top-selling and award-winning Jira Solution Providers...
So that's Tempo as a company: let's dig into the tools! They have three specific tools that we're going to be discussing today: first is Tempo Timesheets!
Tempo Timesheets really makes time tracking in Jira easy and accurate by extending the out-of-the-box time tracking functionality. It allows you to plan and log your work using a calendar directly from a Jira issue, using a tracker or even the mobile app to track on-the-go.
There is plenty of built-in reporting to understand where time is being spent, and you're able to account the work to ensure that time is allocated correctly. Tempo budgets is a Financial Project and Portfolio Management for SMEs and large-scale distributed enterprises. It is able to work within traditional or Agile methodologies, including Scaled Agile framework. It allows you to manage project scope schedule and costs efficiently and in real time, so what it gives you is a roll up of data from the project to the portfolio level. It allows you to take the work that is being tracked within Jira and know where it goes.
For some more information on how Tempo Budgets can be used for Lean Budgeting in Jira, particularly when using SAFe or Scaled Agile Framework, check out the recent white paper published by Amanda Babb, a principal here at Praecipio Consulting.
Last we have Tempo Planner. Tempo Planner lets you plan and manage work for your teams, and really maximize the use of your organization's resources. It lets you increase the transparency of your plans and your planned work to really get more of a greater team efficiency.
All three of these tools are really closely integrated within Jira and with each other, allowing a seamless experience while moving through the process all the way from the developer or analyst who is working on a Jira issue when logging the time, all the way up to how those hours that they logged track against your budget.
Alright so now that y'all have some background on Tempo Agile Project Management, let's jump into a few ways that the Tempo tools are able to really facilitate that process. We can get through those high-level benefits and ways that Tempo helps you avoid those common mistakes, avoid them, fix them do whatever you can to to make sure that you're not stuck in that same boat.
I mentioned visibility a little bit earlier when talking about not hiding your budgets. I'm sure some of you cringed at that idea, but really within Tempo all three products: Timesheets, Planner and Budget, you have the ability to restrict visibility at many different levels. What this means is that you can open up high level reporting to end-users, you can give them the visibility to see how you're progressing on the budget, how costs are tracking; to really understand the state of the project. You can go all the way down into the nitty-gritty and see specific dollars per resource, or dollars per issue. Really, that visibility is essential and you've got a lot of granularity here. I definitely recommend when using Tempo letting your the project team and your team be able to see how you're tracking; an informed team can make better decisions when working with their PO or PM, and you can still lock down things that might be more sensitive: things like cost rates. Maybe you don't want everybody on the team knowing how much you're charging for each developer: you can lock it down at that level, but still give everyone the visibility to to know what's going on. You can do that within Tempo through Budgets and Timesheets; Using reports and even putting the data on dashboards.
Estimation is an essential part of Agile as a whole; Tempo Budgets in particular allows you to estimate your work however you choose, whether that's story points, hours or any other statistic that your team may use. You can estimate that way while still tracking actual time logged, so you can get those story points from the dev team and compare it to how much the work on those issues actually cost the organization and the project, and track that against your budget.
Within tempo budgets you can look at progress against estimates using that those actuals, that are those time logs. This can be a bit scary for project managers first working in the tool, every story and task won't be estimated when you start a project, they shouldn't be estimated when you start a project, but as the team begins digging into the work and breaking it down into smaller pieces then they'll get into really the thick of estimating how long the work will take them, and so as you get closer you'll have a more realistic view of the time that might be needed or the work that needs to be complete.
Tempo has the ability to define teams: these can be defined dynamically and really allow for things like Timesheet approvals, being able to track resource costs and reporting on allocation across the different users in your Jira instance.
Teams in Tempo can be defined in many different ways, my recommendation and the way that you can really get the most agile implementation of this tool and this toolset is to define teams using your agile teams. Within a waterfall organization, your project teams are not consistent, it's not the same team working together as the weeks months years progress; but within Agile the idea is that you have really defined consistent teams. Teams that work together regularly are able to get into I guess more of a groove, they're able to estimate together, they're able to become more predictable, which really allows you to to forecast and project better when you have these more predictable teams.
From a technical standpoint, when using Agile Teams, the the use of of Tempo is is definitely simplified, so you don't need to go manage the teams as they change for each project, you don't need to figure out who is allocated here for this percent, although you're able to. Within Tempo Timesheets and Planner you're able to allocate users across different teams, but if working with Agile teams, ideally, you'll have a team that is a hundred percent dedicated working together and really helping you produce those those consistent results.
Just because you're running at all doesn't mean that you can't plan, and of course all three Tempo tools allow you to plan against your issues, and even Jira projects. You can take the issues in your your team's backlog, and plan them for users; you can let users plan for themselves; and then you can translate that into dollars, into projected and planned costs.
Tempo has a really user-friendly drag-and-drop planning functionality. This can be used during sprint planning with the team to visualize who will be completing which pieces of work with a really easy view of the estimates that are associated with this. With in Tempo Budgets you can even take those plans and then translate them directly into estimated costs.
The difference here with what you might be used to is that the issues that you're planning against should be broken down into small consumable chunks, and really defined in great detail only in the shorter term. The idea here is that you're still planning, but the work that needs to be done, if you're planning for six months ahead, what needs to be done in six months could change: probably will change. The idea here is that you're planning in the shorter term while using that predictability and reliability of these teams to get those forecasts for the future.
Here on the screen we have an example of what that drag-and-drop planning functionality looks like with in Tempo Planner and Tempo Budgets. This is just one way to work within this the suite, you can see pretty clearly on the right side you've got a list of issues that are available, these can be filtered down based on the team here. And then you can drag those onto the screen: it will dynamically lengthen the issue out based on the estimates that have been provided.
In this example we see that we're estimating in hours, so it's able to distribute those over the days available. We can see which team members have have work planned for them this week and who may not. You can track this at any level, so we can do it at the story level, or at the epoch level; from a longer-term planning perspective you might plan users towards epics, capturing that larger bucket of work rather than digging into these specific stories that might not be well defined or even defined at all.
If you think that time tracking isn't as important in Agile Project Management as budget or resource planning, you are wrong! Not only are you able to compare planned hours to actual hours, but you can actually see how your estimated costs for a project compared to the real work that was done tied directly to the Jira issues that the team is working on. Using some of the out-of-the-box reporting with Tempo, specifically with Tempo Budgets, you can identify cost per issue, high-level reporting on plan versus actuals, and be able to forecast what those costs will be by the end of the project.
So of course your forecasts aren't perfect just as they aren't in any project management tool, however what this gives you is the benefit of the actual work that team members are working on in logging time against, and the ability to to generate what's called a completion ratio. Even if you haven't defined all of the work for the entire project, you can see the rate at which or the velocity that your teams have in completing the work, to be able to more reliably forecast those costs.
To wrap this up, I just really love this quote by Martin Suntinger, from Atlassian: “A realistic and data-driven forecast can cause feelings of shock and disillusionment”. A transition to Agile Project Management or even just adopting some of these tenets means things may look different, but that's good! It's good, we like to have the control or the idea that we can forecast what a two-year project is going to look like, but we we know that that's not really quite realistic when you're using Project Management tools that are connected to the work that's actually being completed. You're able to remove some of the silos that we see in traditional or waterfall Project Management.
Atlassian and the Tempo suite are able to provide visibility and support in planning, budgeting and tracking your projects. They really make it easy to avoid some of those common mistakes, things we talked about earlier like setting all of your hours and all of your plans at the beginning. Because we've broken down the walls between the team doing the work and those who are planning against it or tracking it, these metrics are immediately available, easy to understand and you can really see that data just right up front. Stage gates: right out of the gate Agile Practices make these unnecessary, but also the easy reporting, visibility and forecasting within the within Atlassian and the Tempo tools.
Now let's go ahead and get to these questions. First question: Can different projects estimate differently? I've got one team that estimates using time and other estimates using story points. A: Yeah that's a great question! Each project or Folio with in Tempo Budgets can actually set what field in Jira it uses to estimate progress; so what this means is that one project can use story points while another can maybe estimate in time or however you want to estimate and then when you're looking at a comparison or a rollup if you want to compare the two you'll get a percentage complete or a percentage of progress. So you're able to really see those next to each other and it doesn't matter what estimation statistic anyone's using.
Alright, for our next question: in Tempo Budgets, can I plan costs based on who is assigned to an issue? A: Yes, absolutely! When you are determining your planned costs you would actually pull in issue plans either from Tempo Planner or Budgets, or you can pull an issue assignments or you could even just distribute the costs based on availability to the entire team. So what this does is use the estimates of the issue, time, whatever cost rate the users have, to determine those plan costs.
All right our last question for the day: Are you able to set budget baselines with in Tempo? A: Yeah that's a really great question! You are actually. So once you've planned your costs for resources and expenses within the tool, you're able to approve a budget and then compare that baseline with your actuals. Baselines aren't necessarily set in stone: you're able to re-baseline if any major changes occur, and reports will compare your recent baseline to your actuals. What it does is still saves your original baselines or past baselines so you can keep keep that visibility within those.
Join us again for our next webinar: Atlassian Summit Takeaways, and AMA with the Praecipio Consulting Partners, will be on May 8th at 11 a.m. Central.
That's a wrap folks! Thanks for joining us today. We'll be sure to send a recording of this webinar soon so be on the lookout for that. Have a great day!