Agile Project Management

Story Cycle Time Now Excludes Weekends!

2019-11-20T11:24:43+00:00

The Tracker Team has been working on an exciting update that makes your team’s Story Cycle Time more representative of the work that your team is doing. This update is now live for all projects and applies to your past and future cycle times.

Cycle Time

In Tracker, Cycle Time is the median number of hours that your team spends on stories. It measures time from when a story is first started to the final date it is accepted. If a story is unstarted and/or accepted multiple times, Tracker uses the earliest start date and latest accepted date to calculate cycle time.

Updated Story Cycle Time

With this update, Cycle Time still calculates the median number of hours that your team spends on stories, but excludes weekends based on your project’s timezone. If your project doesn’t have a timezone set, you can add one in Project Settings.

You can see this change in Analytics, on the Project Overview tab. In the section for Cycle Time, click the view report link to be taken to the full report, or select Cycle Time from the navigation menu on the left.

Additionally, all weekend activity on started stories is excluded from the Story Cycle Time report page, which means weekend hours will not be added in the report for stories remaining in Started, Finished, Delivered & Rejected states.

While we’re here, for holidays or other times when your team members aren’t all working, you might like to use Team Strength. While Team Strength has no impact on cycle time, it helps keep velocity (and therefore work per iteration projections) accurate, and is a visual cue in your project that anything unexpected in analytics, like a longer cycle time, might be influenced.

What do you think? Please share your feedback in the comments below, by emailing us at tracker@pivotal.io or using Provide Feedback under the Help menu in Tracker. We love hearing from you!

Time tracking for agile software teams

2019-10-21T11:24:43+00:00

This guest post is from Alla Chernets at Tmetric, an online time-tracking tool that allows users to track the time spent on various projects and analyze productivity.

The first fact about time tracking that springs to mind is that it is the least exciting thing within the development cycle. Not many developers in sprints think: ‘Oh, cannot wait for tracking time on EVERY task!’

And there is a justification behind this skeptic view. After all, in agile it is all about two things: what is next and what is left.

Right? Well, wrong.

Agile approach

Agile project management has been in practice in the software development sector for almost 20 years, and Agile statistics confirms its growing popularity as the widely applied technique in SDLC.

In particular, opting for the Agile framework brings more successful project completion in 28% cases compared to projects where teams were using the traditional methods.

Overall, the agile approach allows to perform and timeline the project with prioritized tasks assigned to different team members.

Why is time tracking a must-have workflow component for agile software teams?

Because agile, among other things, is about the high level of adjustment to changes, and tracking and collecting time data bring consistency to the process that otherwise might result in interim mistakes, catastrophic mismanagement and failed sprint.

Agile in practice means that at all the stages including design, analysis, or testing, the process goes with lots of room for changes in mind.

Naturally, to avoid time loss and ensure the smooth workflow, time tracking software comes as an optimal solution.

Time tracking in Agile estimation

Agile approach implies working in self-organizing teams. They usually create the product while constructing the development process around test and result-oriented strategies as the basics.

In either scenario, the team aligns its work with the specific requirements, and in both cases, time is one of the crucial factors. The team may consider estimating in story points for defining tasks complexity. But then, within a sprint plan story points will relate to the hours allocated to work.

To meet the multiple micro deadlines and harness development cycle time, the team creates estimates for conducting tests (it will define the quality of the team’s work) and achieving the result (it will eventually define the value of the product).

For the projects incorporating the recurring tasks, time estimates can be easily calculated by data kept for the previously performed projects, and it is where automatic time trackers can come handy as the verified metrics can set the subsequent estimates.

In other cases, creating estimates is guided by professional experience and intuition.

Additionally, including more people into a team increases communication volume so, for the sake of keeping the high collaborative level within a big team, communication overhead incorporates into time estimates of the agile team. To avoid uncertain numbers or prevent time overrun, the time data on previous sprints is taken into consideration.

The development cycle is not a process rigidly set once and for all in terms of time: at some stages of the project, waiting for other team members is a part of working in collaboration.

In this case, time tracking will be an effective instrument of monitoring team performance and analyzing estimates against actual entries to see when the process blockages were justifiable. For example, TMetric time tracker that lots of software teams favor packs metrics on detailed time entries and activity level in one neat timeline, which gives the clear view of time consumption alongside with a team member performance.

Upon completing estimates creation, the team starts tracking the project. Later on, teams measure how the actual work compares to their original estimation.

Time tracking in Agile evaluation

In Agile methodology, the excellence of design and attention to technical detail are two major principles. Furthermore, a final product satisfying the needs of the client is the primary source for evaluating the overall success of the project. To ‘glue’ stages and make workflow seamless, time tracking comes as one the essentials. Upon the development completion, the collected time entry data make the evaluation truly effective by providing the relevant information on the accurate assessment of the performance.

Factors supporting time tracking in Agile evaluation:

Focus on delivering the results in compliance with the project requirements
Focus on team needs in terms of distributing the workload
Ensuring effective communication

Time tracking software ideally fits in the Agile software development as both a team and a time management tool that enables you to streamline the collaborative efforts of the software team.

At the stage of evaluation, there is no better way than bringing time measurements to the table as they are the only accurate way to measure the pace of work.

Time metrics stored in the time tracking records maintain the valuable information that is easy to transform into specific data for analyzing and understanding the work that has been done and the overall capabilities of the team.

Generally, time tracking records will be helpful for evaluating:

Team performance
Effectiveness of the development process
Justification of chosen strategy
Priorities settings.

In particular, within Agile evaluation, automatic time tracking data enables developers and managers to have the validated clear analysis of time utilized on:

Planning backlog
Pulling user stories
Performing individual subtasks
Syndication of team reports
Creating an agenda for meetings with clients
Research, analysis, design and testing.

Practical benefits of time tracking in Agile

The development process must adapt to changes in the market environment, that is highly oriented to customers’ needs: under these conditions, time tracking works as a practical solution in agile teams’ work that can prevent issues with prioritizing and extensive planning.

Though time tracking in agile projects used to be optional, now it shifted to the domain of must-haves in project performance as it became apparent that the deadline is not the only component determining the project success, and in most cases, lack of metrics related to time utilization translates into unavoidable management pitfalls and misinterpretation by clients.

So regardless of development complexity, time tracking enhances the agile software teams performance.

Practically speaking, time tracker ‘articulate’ figures for ensuring time management as an important factor of success of software development projects.

Agile software teams can take advantage of time tracking for:

Keeping time utilization within a highly changeable process under control
Maintaining track interactions with clients by estimating billable and nonbillable hours
Innovation type of the project can be projecting on time allocated; if the team overruns in time due to project complexity, the client will have the transparent reporting on what the time was spent on
Automating work process according to the modularity of tasks
Reducing the impact of interim mistakes because the scrum master can monitor the team workload and distribute it among the team members so that they do not get overloaded and the team could meet deadlines.

The time tracker applied in agile software team collaboration benchmarks the progress of an individual. It allows to see team velocity and assess the data in burn-down charts to ensure precision and adaptability to changes in sprint length.

So regardless of development complexity, time tracking enhances the agile software teams performance due to providing the specific metrics of forecasting value. Afterward, it also helps identify bottlenecks in the process for further preventing any kind of time management pitfalls.

By obtaining metrics measuring the cycle time of separate stories the agile software teams can work more productively. Therefore, applying time tracking software is an effective method of increasing velocity and responsiveness by enhancing agility with specific result-driven metrics.

Concluding Thought

Though time tracking in agile projects used to be optional, now it shifted to the domain of must-haves in project performance as it became apparent that the deadline is not the only component determining the project success, and in most cases lack of metrics related to time utilization translates into unavoidable management pitfalls.

Time tracking shifts focus from calculating time to investing efforts. The fact that you can see accurate time consumption data for accomplished tasks at the end of each sprint by using time tracking is what creates accountability and builds solid grounds for efficient collaboration.

Alla Chernets has been providing informative reads for TMetric blog for a year. Her articles focus on productivity and explorations of the ways to achieve the best results and get more agile.

Shorter Iterations are always best…and Other Lies you’ve been Told

2019-08-26T11:24:43+00:00

Often teams first begin their agile journey with an iteration-based methodology, such as Scrum. This is because the dependable cycle of iterations that these methodologies impose on teams introduce a feeling a stability and predictability.

However, after a team finds success with an iteration-based methodology, it’s often not long before that same team starts to hear the siren call of shorter iterations.

Understanding the true value of shorter iterations

And why not? After all, shorter iterations certainly come with some advantages. But the most commonly cited advantage of a shorter iteration is actually a misconception.

Often teams, as well as their organizations, are lured into shorter iterations by the promise of faster development. After all, if an agile team working in 2-week iterations seems to move faster than their non-agile counterparts, then that same team working in 1-week iterations should move twice as fast. Right?

Not exactly. Working in shorter iterations actually allows teams to deliver sooner…which isn’t quite the same as moving faster. While the ability to deliver sooner is still advantageous to teams, it’s important to recognize this distinction.

Teams working in shorter iterations may not necessarily produce code at a faster rate than those teams working in longer iterations, but they will deliver that code more frequently. And this higher rate of delivery means that these teams will become more adaptive, both in terms of their product and their process.

Teams who deliver code more frequently are better positioned to measure the market’s response to those deliveries and then adapt their product strategy accordingly, improving their chances of success. And by the same token, these same teams are also afforded more opportunities to reflect on their own product delivery process and to experiment with changes in hopes of improving that process even further.

Measuring the efficiency of your team’s iteration

However, longer iterations are not without their benefits, either. The most commonly cited benefit of longer iterations is that they tend to be more efficient. However, this often isn’t as straight-forward of an assumption as it first seems.

Many teams believe that the greater efficiency of longer iterations stems from the fact that a smaller proportion of the team’s time is spent in planning and review events, as opposed to delivering the work at hand. But the flaw in this assumption is in failing to realize that as the time to the next delivery increases, the amount of planning that must occur between those deliveries must also increase. In fact, this point is so salient to teams who are following the Scrum framework that the Scrum Guide provides explicit guidance to how the duration of a team’s planning events are expected to change as the length of their iterations, known as Sprints, increase.

For example, for a 1-month Sprint, the Scrum Guide recommends a Sprint Planning event of 8 hours but also specifies that this event should be proportionately shorter as the Sprint decreases in duration. This awareness of how a team’s planning commitment changes in relation to the length of their iteration tells us that it’s unlikely that teams will spend a smaller proportion of their time in planning during longer iterations.

Enabling focus on your team

But even without the reduction in the proportion of time spent planning, there is still one major benefit to longer iterations. This benefit is that your team is able to work for a longer period of time on a single set of tasks without interruption. This longer period allows your team to build momentum in their work, attain greater focus, and increases the chances of your team achieving a state of flow. This single benefit alone is often enough to justify working in longer iterations to most teams.

There’s also one other key benefit to longer iterations that, at first, may not be as obvious. While the higher frequency of delivery of shorter iterations enables a team to be more adaptive to changes in the market, this higher adaptability can also result in thrashing for a team whose Product Manager uses that adaptability to chase a new opportunity every iteration.

A longer iteration encourages Product Managers to redirect their team’s focus less frequently, which gives Product Managers more time to reflect on new opportunities and decide whether they’re the best use of their team’s time and energy. This helps to maintain their team’s focus longer, which can result in that team being more effective over the long term.

Finding the right iteration length for your team

As we’ve discussed, both shorter and longer iterations each have their own advantages. So, if this is the case then how do you know which is the better choice for your team?

The right choice of iteration length for your team is likely to be more a function of the specific product that your team is building, and where it is in its lifecycle, rather than of your team itself. A newer product, whose team is still trying to identify the optimal vision and strategy for that product, often benefits from the greater adaptability afforded by shorter iterations. This is because the higher frequency of delivery enables more experimentation by the team and faster decisions based on the results of those experiments.

More established products, on the other hand, whose vision and strategy are largely established are more likely to benefit from longer iterations. While long stretches of time between opportunities for feedback does increase the risk to your product, established products tend to be more stable and carry less risk between deliveries so they are less prone to this risk than a younger product.

For this reason, many teams find it beneficial to begin development of a new product with shorter iterations and use these iterations to quickly identify the most promising vision and strategy for their product. After the product’s most likely path to success has been identified, then these same teams will often evolve towards longer iterations to take advantage of longer periods of focus as their product matures.

Shorter isn’t always better

The prevailing belief that shorter iterations are always better for all teams is a fallacy. While both shorter and longer iterations have their own benefits, the right choice for your team depends more on the product that your team is building and where it is in its lifecycle.

This means that your team is likely to see the most benefit by allowing the needs of your product, as well as what decisions are most likely to make that product the successful, drive their choice of iteration length.

Jeremy Jarrell is an agile coach who helps teams get better at doing what they love. When he’s not mentoring Scrum Masters or Product Owners, Jeremy loves to write on all things agile. You can read more of his thoughts at www.jeremyjarrell.com, see his videos at Pluralsight, or follow him on Twitter @jeremyjarrell.

Measuring the Business Value of your Stories

2019-08-12T11:24:43+00:00

Many agile teams have become obsessed with speed. How fast can we release? How fast can we close stories? How fast can we deliver to market? What too few fail to realize, however, is that none of this speed matters unless what the team is delivering is actually providing value to their organization.

But how do you measure the value that your team is delivering? One of the most common methods of measuring value is by assigning business value points to the stories in your product backlog. These points can be assigned at the sole discretion of the product manager or may be arrived at in conjunction with the delivery team, via a collaborative exercise such as the Business Value Game.

Tracking the business value that your team creates

But why take the time to assign business value points to your stories in the first place? There can actually be many advantages of assigning a business value to the items that your team is working on.

One such advantage is that assigning a quantitative business value allows you to subjectively track the amount of business value that your team is generating each iteration. You can easily do this by creating a business value burn up chart that tracks your team’s accumulated business value each iteration, or even by adding an additional series representing business value to your team’s existing release burn up chart.

A release burn up chart that tracks the complexity points a team has completed each iteration as well as the resulting business value that team has delivered. Note that even though the team has continued to deliver strong through iteration 8, their resulting business value has plateaued since iteration 6 resulting in the organization receiving diminishing returns from the team. Hmm…

Separating value from complexity

But another, perhaps more important, benefit of assigning business value to each of your team’s stories is that doing so allows you to better understand how the business value each story is expected to yield relates to the expected complexity of that story. Often times, we assume that those stories in our backlog with a high estimated complexity are also those stories which are likely to yield the greatest value. However, this isn’t always the case. By tracking the estimated complexity of each story you can more easily spot cases where the expected business value of a story doesn’t seem to align with its estimated complexity, such as instances where a story is estimated to be very complex but yield comparatively little business value.

By identifying discrepancies between a story’s complexity and the expected value that it’s likely to yield, you can begin to consider options for splitting that story in a way that maximizes the value your organization receives in return for your team’s effort. When doing so, you’ll find that many stories can be split into smaller components upon closer inspection.

For example, imagine that you’re the product manager for an ecommerce app. Your app currently accepts credit card payments via a third party payment gateway for two of the most common credit card vendors in your target market. However, your customers have also asked for support for additional cards, as well.

In response, you’ve added a story to your product backlog which adds support for 3 of the additional credit cards your customers have requested. Since your app already supports the most common credit cards, you assign a fairly low business value estimate to it. However, once your team estimates this story you’re shocked to learn that the complexity of this story is significantly higher than you expected.

But rather than simply discarding the story you decide to ask your team for more details. In doing so, you learn that the two of the new credit cards you’ve chosen are actually supported by your current third-party payment gateway. Therefore adding support for these cards is simply a matter of enabling them in the current gateway.

However, the third credit card is actually a bit more obscure and is not supported by your team’s current payment gateway. They have found another gateway that supports this card, but adding support for it will result in integrating an entirely new payment gateway as well as updating the app’s architecture to support switching between multiple gateways depending on the credit card the customer chooses. Armed with this new information, you’re able to split this story into separate smaller stories for each additional credit card, adding support for the first two credit cards immediately and deferring support for the third, more obscure card, to a later date. As a result, you’ve maximized the value that your organization will receive from their investment into your team.

Avoiding the pitfalls

However, despite all of the benefits that assigning business value to stories can bring, there are a few pitfalls that can befall this practice.

The first such pitfall is forgetting that regardless of how these estimates are arrived at, estimated business value is always subjective. Remember that there’s no greater way to validate your product than market acceptance. For this reason, while estimated business value is an important data point, it’s no more than a single data point in your planning.

Another pitfall is that while business value can be assigned to a story of any size, it tends to provide the most benefit when it’s applied to larger stories. In general, we want our stories to be small as working with smaller stories comes with many natural benefits. Smaller stories tend to carry less risk, they can be delivered quickly, and are easier for your team to understand and work with. But the smaller your stories become the more difficult it can be to quantify their expected business value. This results in a perverse incentive to make your stories larger so their business value can be more easily quantified while increasing the complexity and difficulty of delivering that story for your team.

This means that while you can assign business value to stories of any size, you’re likely to find that this practice yields the most benefit when used at the epic or feature level. In fact, a great use of this practice is to estimate the business value that’s likely to be gained by each feature you’re considering for an upcoming release during your normal release planning process. In doing so, you can best plan for how your team can deliver the most value to your organization in that release.

Maximizing the value of your team

We often conflate the business value a story might yield with the complexity involved in delivering that story. But a story’s resultant business value, and the effort required to deliver that value, may not be necessarily related.

However, by explicitly considering the potential business value of each feature that you work on, you’ll be better positioned to maximize the value that your team can deliver to your organization and your customers.

Time Tracking with TimeCamp - How to Boost your Productivity in Pivotal Tracker

2019-08-11T11:24:43+00:00

So you’ve probably heard about the struggles of project managers and senior developers that also need to report on the team’s efficiency during a sprint. Software developers - do you recall receiving e-mails saying: “Hey Matt, could you please fill out the timesheet for January?” Yes, I can see you frowning upon that - nobody likes unnecessary and boring manual labor - and timesheets definitely fall into that category. So the question is - how you can skip the hassle, and focus on the actual work? Well, thanks to a neat tool called TimeCamp you can automatically track any given computer and online activity. It’s a must-have tool for any professional team that provides hourly-charged services - agencies, software houses, consultancy firms, and others.

With just a few simple clicks you’ll be able to automatically measure the progress of your projects and, most importantly, use that data to generate client invoices.

Sounds good? There’s more - the ancient secret to mastering your teams’ productivity lies in combining the best of both worlds. TimeCamp is offering a wide array of integrations with the industry’s most popular project management and CRM software. And - you’ve guessed it - Pivotal Tracker is among the options - Yay! So in simple words, it means that now you can track the time spent on any of your user stories in Pivotal Tracker and have a clear idea of the time spent for any feature or sprint.

Pivotal Tracker integration with TimeCamp - a simple step-by-step guide

In case you’re worried that integrating Pivotal Tracker with TimeCamp might be something difficult - fear no more. Below is a simple guide that should ease your worries.

Before you start, make sure that you have:

A new TimeCamp account - you can register for a free 30-day trial
A couple of minutes to spare
A cup of coffee (or tea, or any other beverage of your choice)

STEP 1

Once you log into TimeCamp, navigate to the settings section and select the Add-ons bookmark.

STEP 2

Find Pivotal Tracker on the list of available add-ons and click the “Enable” button.

STEP 3

Simultaneously, open a separate tab in your web browser and log in to your Pivotal Tracker account. Then, you’ll need to copy your API token (unique for each user). Click on your username in the upper right corner to open the drop-down menu and select the Profile section.

STEP 4

There you’ll find your API token at the bottom of your Profile Settings page. Copy it.

STEP 5

Go back to TimeCamp, paste your API key to the highlighted field and click “Enable integration”

STEP 6

Now, TimeCamp will automatically import all of your projects and story cards from Pivotal Tracker. They’ll be divided into three categories: Current, Backlog and Done.

And there you have it, now you’re able to track time for any of your Pivotal Tracker activities. Told you that it would be simple, huh?

If you’re experiencing any issues regarding missing projects in TimeCamp, make sure that you’ve checked the “Allow API Access” checkbox (in the Project’s Settings.) It might also be worthwhile to check if the owner of the API Token provided to TimeCamp is a member of the missing project.

So, are you ready to bring in more efficiency and a sense of order to your daily work? Give it a try, and you’ll soon wonder how you ever got by without Tracker and TimeCamp!

Jakub Szyszka - Content Marketing Specialist at TimeCamp. Immersed in the adventurous world of content marketing and brand building.

What to do when Individuals are Unhappy in their own Teams…Or the Fallacy of Team Rotation

2019-07-30T11:24:43+00:00

Few would argue with the benefits that can be gained from a switch to an agile approach. Agile teams enjoy more autonomy and greater fulfillment from their jobs while organizations enjoy faster time to market and and an increased ability to respond to the emerging needs of their customers and marketplace.

But, even with all of the benefits of an agile approach, occasionally some individuals will still find themselves unhappy or even feel trapped in their current team assignment. In fact, it may even seem as if we encounter this more after teams begin following an agile approach. However, there are actually two, very legitimate, reasons for this.

First, teams who follow an agile approach tend to work in small teams, which can exacerbate an unhappy team experience. For example, it’s much easier to tolerate working alongside someone you don’t quite see eye-to-eye with in a team of 15 rather than in a team of 5.

And second, most agile approaches encourage us to be more reflective about our working environment and then to share those feelings with our organizations. In fact, many agile methodologies even have specific mechanisms built into their frameworks to elicit these feelings from their teams in a productive manner, such as the Scrum framework’s Sprint Retrospective. This means that while those feelings may not be new to an individual, that individual simply may not have had an effective way of communicating their feelings to their organization before their organization adopted an agile approach.

Understanding the challenges of rotating individuals

To help alleviate these feelings of unhappiness, some organizations experiment with regularly rotating individuals across teams. This can be tempting, as the opportunity to move teams can not only reduce burnout in team members, but also introduce the promise of a reprieve for individuals who may be unhappy in their current team. But while this option may at first seem reasonable, it may not always be the best solution.

For one reason, each time the composition a team changes the dynamics that have formed on that team also change. This means that the remaining team members must go through a period of readjustment as they learn to be productive under the new dynamics that have emerged on the team. In fact, Tuckman’s stages of group development is a model often cited by agile coaches that exists specifically to model the dynamics that emerge during team formation.

In addition, regularly rotating individuals across teams can also create other problems which are often felt across the wider organization. The most nefarious of these problems is that the team never seems to stabilize so their output suffers. As a result, the constant changes in team composition also tends to result in corresponding changes in the the team’s velocity, which makes it difficult for the team to produce value with any predictability. This is before we even consider the aspect of team members never quite settling in to a team because, no matter how successful that posting may be, they know that in their organization no team posting is ever permanent.

And finally, any attempts to institute a process of regularly rotating individuals across team by an organization’s management is likely to be met with suspicion and resentment from the team itself. This is largely because management-instituted policies which focus on a team’s composition infringe on the team’s right to self-organize, which is a fundamental trait of all agile approaches and key to a team’s long-term success.

Finding the solution

Rather than asking your organization to rotate team members on a regular basis, a better solution is to introduce the concept of an open team. Under an open team approach, any team member can move to another team at any time.

However, as appealing as this might first sound, it’s often not as simple as it seems. One challenge with this approach is that the sudden departure of a team member can open up a sudden gap in the team. This gap can be even more painful if that team member is key contributor or if they have a specialized skill that can be difficult to replace.

It’s also worth mentioning that this approach is often more successful in product organizations than in service organizations. In a product organization, users typically only interact with the end product, rarely interacting with the team directly that produces that product. As a result, the customer is abstracted from changes to a team’s composition. However, in many services organizations the individual members of the team may interact closely with the organization’s client. In these situations, clients will often form attachments to certain high-performing members of the team and resist any changes which could result in those members leaving that client’s project. This can make it very difficult for an organization to honor a request from an individual to leave a certain project without also risking the alienation of key client.

To remedy this, successful open team approaches are often implemented in collaboration between the individual team member and the broader organization. Rather than simply allowing a team member to pick up and leave on a moment’s whim, this approach is most successful when a team member expresses their desire to move to a new opportunity and the organization agrees to facilitate that move when the timing is optimal for everyone involved.

Embracing the freedom to choose

However, under an open team approach individuals do not actually move between teams as often as you may expect. Recall that many of the feelings of unhappiness and dissatisfaction a team member might feel stems from that individual’s feelings of being trapped, but we tend to feel trapped only when we’re held against our will. Once we are granted the freedom to move, many of these same feelings largely dissipate. In addition, this same freedom is often enough to encourage team members to work out their differences with other individuals, rather than simply allowing those feelings to fester.

Finally, whenever we’re free to choose our own team we tend to be much happier with that decision over the long term. One reason for this is that we’re much more likely to choose a team that’s a better fit for our skill set and personality whenever we’re free to make that decision ourselves. But a more important reason is due to our own confirmation bias: whenever we make a decision, we tend to be much more reluctant to admit that decision was wrong than if someone else made that decision for us. Due to this bias, we’re more incentivized to work to make that decision successful to better confirm our original decision, in the first place.

Making your teams accountable for their own happiness

While it may first surprise to you to encounter someone who is unhappy on their current team there are legitimate reasons why these problems may be more likely to appear than in the days before agile.

But by creating a culture in which your team members are free to express their concerns as well as by giving those team members greater accountability to remedy those same concerns, you’ll find that your teams are much more likely to self-organize into happy and successful teams that can add value to your organization for long into the future.

Introducing new Bitbucket and Bitbucket Server Integrations

2019-07-25T11:24:43+00:00

Back in 2018, Pivotal Tracker built an integration with GitHub, making it much easier to connect your code to stories. But this didn’t help those of you who use other Source Code Management tools. That’s why we are excited to announce our new Bitbucket and Bitbucket Server integrations!

Next time you want your Bitbucket branches, commits, and pull requests to show up in Pivotal Tracker, just add our new integrations!

So what does this integration do?

Automatically attach pull requests, branches, and commits*

Adding pull requests, branches, and commits in Tracker is a great way to improve your team’s development process, but attaching them manually can turn into an afterthought. These integrations automatically connect your code to stories and epics.

*Note: The API for Bitbucket Server does not currently support commit messages. We’ve submitted a feature request to their team, which you can track here.

Pull requests

Pull requests make it easier for developers to collaborate and discuss changes before shipping to your main project. Bitbucket pull requests attach to your Tracker stories and epics so that everybody involved can quickly access the work and review the changes.

Branches

Branches enables developers to separate pieces of work from your main master branch. On the Tracker team, we create a branch for every feature and work on that branch until the feature is finished. Similar to pull requests, our new integration will automatically connect branches to the Pivotal Tracker story or epic you are working on.

Commits

Commits represent units of work that are committed to a repository. We link your developers commits in Bitbucket in the activity on Tracker stories. You can easily refer back to work done and never have to leave your Tracker story.

How to get started

For information on setting on our new Bitbucket and Bitbucket Server integrations, please review the linked support articles. If you have any difficulty setting this up on your project, please contact us at tracker@pivotal.io.

Not using Pivotal Tracker and Bitbucket?

Stay tuned for more SCM integrations coming soon!

Getting Started With Agile: Putting Agile to Work for You

2019-07-15T11:24:43+00:00

Throughout our Getting Started With Agile series, we’ve dove deeply into each of the 4 main values of the agile manifesto. During this dive, we’ve unpacked not only the intent behind each value but also the underlying ideas and concepts that led to the creation of that value.

In this final installment in the series, we’ll discuss concrete strategies for applying each of these values so you can put these ideas into play with your own team.

Individuals and interactions over processes and tools

The first value of the agile manifesto stresses the importance of the interactions that occur on our team over simply relying on processes or tools. Few would argue the importance of this, but how do you encourage these interactions on your own team? The first step is identifying how well your team is collaborating in the first place.

While it can be easy to recognize pockets of healthy of collaboration on your team, spotting a lack of collaboration can be more difficult. A great place to start is understand how reliant your team is on your existing processes and tools. For example, does the majority of your team’s conversations seem to happen only on comment threads in your project management tooling?

If so, then it might be time to take a break from this tooling to see if doing so encourages more face-to-face interactions on your team. To do so, try stepping away from your favorite project management tool for an iteration to see how your team solves for situations where conversations can no longer occur from a keyboard. With any luck, you’ll find that your team learns the benefits of communicating in real-time throughout the day and even seeks out more opportunities to do so.

Even if you decide to bring this tooling back into your process at later a date, your team is likely to have a newfound appreciation for the true value that it can provide along with a healthy wariness of the dangers of over-relying on it.

Working software over comprehensive documentation

The second value of the agile manifesto reminds us the only true measure of progress for our team is delivering working, usable software. All other measures, such as design artifacts delivered, documentation created, or even velocity, are nothing more than supporting actors in service to this goal. But what do you if your stakeholders seem to be focusing on the wrong measures of success for your team?

If you find yourself in such a situation, then your first step is to shift the conversation to uncovering the actual value that your team is trying to produce. Once you’ve done so you can then discuss how the current measures that your stakeholders are focused on map to that value.

Maybe your team is seeking to increase sales by adding new and differentiating features to an existing product, or maybe your team is seeking to improve your organization’s operational efficiency by streamlining an existing tool used deep in your organization. Whatever your team’s goal is, odds are that the number of pages of documentation that they are producing along the way isn’t the best measure of whether they’re on track to achieving it.

Once you’ve helped your stakeholders see that your current measures of success may not be as informative as they once believed, you can then begin to explore other measures that may be more indicative of your team’s progress.

Your next iteration review is a great place to start this conversation. You can begin by reviewing what the goals of your project actually are and then discussing whether the progress your team has made since the last iteration review has actually moved the project to its the goals. Once everyone has a better understanding of what progress actually means, you can then begin to tease out more meaningful measures of success of each increment of working software your team delivers. This may include metrics such as user adoption and satisfaction, uptime or other quality metrics, or revenue directly generated as a result of that increment. Whatever metric you choose, as long as it’s dependent on the delivery of working software, you’re likely to find that it’s much more indicative of your team’s long-term success than number pages of documentation written.

Customer collaboration over contract negotiation

When was the last time you interacted directly with your customers? At the last iteration review? Only after the last release? Not since your project kicked off? Customers who?

The third value of the agile manifesto, reminds us of the importance of working closely and collaboratively with those who are the most likely to hold the key to our success…our customers.

Time and time again we see that one of the greatest predictors of a project’s ultimate success is how closely that project’s customers are involved throughout the process. But even with this experience, many teams are still hesitant to invite their customers into the fold.

For many teams, encouraging deeper involvement from their customers pushes them out of their comfort zone. In addition, many customers simply look to their development teams as the experts and are unaware of the value that they themselves can bring to the conversation. But regardless of the reason that collaboration does not occur, it’s our responsibility as agile software development professionals to bring our customers into the conversation.

A great place to start is to begin inviting your customers to your team’s iteration review to give them the opportunity to provide feedback on work that’s in progress. But once they’re there, don’t give them the luxury of simply sitting quietly.

A successful iteration review is much more than a mere demo, it’s a productive two-way conversation. Your customers should provide constructive and specific feedback to your team on how closely the work that they’ve produced will serve their needs once it’s released. But don’t settle for a simple thumbs up or thumbs down…dig deeper to understand why the team’s work is or is not inline with your customers needs. This will help everyone better understand the ultimate goals of the project and enable your team to make more informed decisions along the way.

Finally, if the conversation during the iteration review reveals that changes to the project should be made, strive to make these changes sooner rather than later. Incorporating changes quickly, even as soon as the next iteration, will help demonstrate to the customer the power that their feedback can have to positively influence the direction of the project, even while it’s in progress.

Responding to change over following a plan

If you’re really putting working software in your customers’ hands each iteration then you’re likely to learn a lot about your product…some of which might be unexpected.

The fourth and final value of the agile manifesto tells us that one of the greatest keys to success of agile teams is their willingness to adapt to change as it occurs rather than insisting on following a predefined plan. Yet, despite this, many teams cling tightly to outdated and obsolete plans even when everyone secretly knows that these plans bear little resemblance to reality.

If you find yourself in this situation, then it’s time to have an honest conversation with your stakeholders about how the reality of your team’s situation compares to the plan that was originally laid out. But don’t despair, all hope is not lost.

There are always options to rethink your plan and still deliver the value your stakeholders need. One of the simplest options is to discuss the impacts of lengthening your schedule. However, pushing the delivery date often isn’t an option for many stakeholders. In these cases, then it’s time to consider whether every feature that was originally desired is still critical to the project’s success. For example, could some features be removed or at least deprioritized to later release?

Finally, there’s a third option that’s often missed by both teams and stakeholders. Rather than removing features or pushing delivery dates further out on the horizon, consider whether the complexity of features that are already slated can be simply be reduced. By reconsidering what the true goal of each feature is, teams often discover simpler and more efficient ways to achieve that same goal as the project progresses.

However, adapting to change isn’t limited to just your project plan. Often our original ideas of how customers will benefit from our project or the needs that it will fall flat once our project sees the light of day. But by listening to our customers’ feedback on each increment of product and incorporating that feedback into future increments, we can continuously adapt and evolve our vision of the needs our project will fill and improve our project’s chances of success.

Putting it all together

Thank you for joining us on this journey to better understand the agile values that comprise the core of the agile manifesto. By building a solid understanding of the ideas that underlie each value of the agile manifesto you’ll not only be better prepared to apply the true ideas behind these values, but also better positioned to recognize opportunities where you can begin applying these values with your own team.

For it’s through the faithful application of these values that you’ll be able to greatly improve the odds of success of your own team.

Summertime brings new SCM integrations

2019-07-09T11:24:43+00:00

Start your summer off right with new Source Code Management integrations

The Tracker team has been hard at work building new Source Code Management integrations for your team to use! Now, you can visualize your development progress within Tracker using your favorite SCM. Include the story ID in your commit messages, pull request titles, and branch names to see them in your Tracker stories. You can also update the status of your Tracker stories by tagging your commits with Finishes, Fixes, or Delivers. Help keep your team up to date and move work forward together with our new suite of SCM integrations!

GitHub

We began this work by restructuring our current GitHub integration to help streamline the flow of attaching code to stories. You can read more about the changes we made here.

GitHub Enterprise

Based on a decision by GitHub to deprecate Service Hooks in their latest release of GitHub Enterprise, we’ve recently added a new GitHub Enterprise integration. For more detailed information on how to set up our new GitHub Enterprise integration check out our support article.

This is only available to Pivotal Tracker Enterprise customers. If you would like access to this integration but aren’t currently on a Pivotal Tracker Enterprise license, please contact us at tracker@pivotal.io.

Bitbucket and Bitbucket Server

Keep your eyes on the Tracker integration list because we will be releasing Bitbucket and Bitbucket Server integrations soon!

Please email us at tracker@pivotal.io if you have any questions about adding an integration or if there are other integrations you would like to see in Pivotal Tracker in the future.

Why Traditional Reports Don’t Work In An Agile Environment

2019-07-01T11:24:43+00:00

We’ve all been there. You’ve started a new agile team and things are going great. Your team is working together wonderfully, your customers are thrilled to be invited into the process, and your organization is absolutely astounded by the amount of value you’ve delivered in such a short time.

But, inevitably, you eventually hear that phrase that no agile team ever wants to hear: “Your team is doing great! When can I see a Gantt chart?”

Understanding why agile reporting is different

If you’ve ever worked on an agile project, then you’ve probably realized that the types of reporting that are beneficial to an agile team are very different than those that are beneficial to a traditional team. This is because agile and traditional project management approaches are based on fundamentally different ideas, and the reports used by these approaches reflect those differences.

One common difference between these two types of reporting is that traditional project management reporting is often based on individual performance while agile reporting shifts the focus to the team’s performance, as a whole.

For example, it’s not unusual to see traditional reports focused on metrics such as lines of code an individual has committed, hours an individual has worked, or bugs an individual has fixed. Agile reports, on the other hand, tend to focus on metrics such as the number of points a team delivered in a previous sprint or the estimated amount of business value delivered in a previous release. These metrics better capture the amount of work that a team has delivered as a whole rather than incentivizing the members of that team to compete against one another.

Another difference is that traditional project management reporting tends to view how well a team is adhering to the project constraints of budget and schedule as the ultimate measure of a team’s success. While these metrics are important, they’re a poor proxy for how your actual customers will measure the success of your product. By contrast, many agile metrics are built around predicting the tangible business value that a team is delivering sprint over sprint as well as how well that work is actually solving your customer’s problems.

A side effect of this is that the reports used by agile teams tend to be less granular since they are often intended to inform the underlying context in which the team is operating, rather than to be used as the single indicator of whether a team succeeded or failed. While this can ultimately lead to more informed decision making and thus better outcomes for the team, it also explains why some traditional managers might feel that agile reports don’t provide the level of visibility they need if they’re accustomed to making decisions from a distance based only on a set of numbers.

Walking a mile in your manager’s shoes

But what if you’re still unable to convince your manager to throw away her Gantt charts in favor of a more agile reporting tool? Don’t despair; you can still find success by taking the time first to understand the underlying needs behind your manager’s requests. Often discovering the reason behind a request not only helps you communicate more effectively with the requestor, but it can also help you better understand what types of reports will best suit their needs.

One way to better understand this is to consider how your manager’s own success is being judged. In particular, what results might your manager be accountable for and how might that accountability incentivize their behavior. For example, is your manager directly accountable for the success or failure of each project under their purview, or are they merely viewed as a reporting channel to the higher level leadership in your organization? The level of accountability you manager has can significantly influence how hands-on they insist on being with your team.

Another way to gain insight into what might be influencing your manager’s behavior is to consider who your manager is reporting to themselves. Specifically, is your manager reporting directly to the C-suite who will be making executive decisions directly from your manager’s information, or are they reporting to a lower level of leadership, such as the VP level, who might be spinning those reports up to the C-suite for their own gain? If this is the case, then taking a few moments to consider the different types of information that each level might be interested in, as well as the biases that might exist at each level, can be very enlightening.

Choosing the right report for the job

The answer to the questions above can help inform what types of reports may be the most informative to your manager.

For example, if your manager is most interested in the day to day activities of your team then a report that tracks your team’s progress at the daily level, such as a Burnup Chart or Cumulative Flow Diagram, might be of the most use. Reports such as these will provide insight into how your team is progressing as well as give your manager more frequent opportunities to step in if she fears that your team may be veering off course.

On the other hand, if your manager is most interested in the long-term view, then she may see the most benefit from a report that provides long-term strategic insights such a Release Burnup. This report can provide guidance as to how your team is trending over the long term, as well as provide an early warning if it appears that your team may be veering off track.

Going straight to the source

These are just two of the agile reports that can add value in an agile context, once you’ve taken the time to understand exactly what questions your manager is seeking to answer.

However, most importantly, you must help your manager understand that reporting in an agile context is but one piece of the puzzle of your team’s progress. If your manager wants to understand the whole picture of how your team is progressing, then the most effective way to do so is to begin interacting with your team on a regular basis such as attending sprint reviews, daily standups, or seeking other opportunities to provide regular feedback.

This is because even the best reporting pales in comparison to the amount of information that can be gleaned from regular interactions with the team.