Stepsize Documentation
Home
  • 🏠 Welcome to the Stepsize Docs
  • 🧠Getting Started
    • Getting started with Stepsize
    • Creating your first issue
  • 🏷️Issues
    • How to create an issue
    • Adding more code and context to your issues
    • How to view inline annotations
    • Converting TODOs into issues
    • How to resolve issues
  • 👥Team & Collaborators
    • How to invite collaborators
    • Setting up Stepsize for your team
    • Using Stepsize as a Team
    • Talking to your Team Lead about Stepsize
    • Talking to your Head of Engineering about Stepsize
    • Talking to your Product Manager about Stepsize
  • 🏁Workflows
    • Using Stepsize in your planning process
    • Using Stepsize in your code review process
  • 😎Talk to us
    • Contact Us
Powered by GitBook
On this page
  • Proving impact with Stepsize
  • Expected results from your experiment
  • The experiment
  • Reviewing the experiment
  • Talking to your Product Manager
  • We can help
  • Set up a call with us 🤙
  1. Team & Collaborators

Talking to your Product Manager about Stepsize

Stepsize works with organisations like yours to unlock unprecedented improvements in velocity, quality and employee retention.

Proving impact with Stepsize

You understand the transformative power of tracking issues directly in the codebase.

But how can you get buy-in from your product manager?

Getting the most out of Stepsize requires both the tool and a process.

In this guide, we'll describe a tried and tested experiment that you can run with your team to prove the impact of Stepsize in driving behavioural change in the way your team creates and resolves issues.

Expected results from your experiment

On average, we expect that over the course of an experiment, engineering teams will...

The experiment

Track one, fix one.

  1. Select a time period for your experiment. This could be 1-2 weeks or a sprint, for example.

  2. Get on the same page. Hold a meeting to kick off the experiment.

  3. Track one. Each engineer documents at least one new issue over the time period.

  4. Fix one. Collectively agree on an issue to resolve as a team. We suggest holding a short meeting to do this.

If you can, record anything you observe which might be relevant to make your case, such as behavioural changes in the way engineers use Jira.

Reviewing the experiment

  • Visibility - How many issues got created? How does this number compare to your normal number when using your standard issue tracker alone?

  • Awareness - How many issues were viewed? How does this number compare to your normal number when using your standard issue tracker alone?

  • Actionability - How many issues did you resolve? How easy were they to prioritise (e.g. using the codebase visualisation – for more information, see our guide)

What qualitative data do you have? For example:

  • What feedback did the engineers have?

  • What changes did you observe in the quality of issues?

Talking to your Product Manager

You've conducted and recorded your experiment. Before you talk to your Product Manager, ask yourself...

  1. Did the experiment improve Jira participation (or whichever tool you use)?

  2. Did the experiment help to expose technical risks? How?

  3. How will continuing using Stepsize with a process like this make it easier to plan predictable sprints?

  4. How will continuing using Stepsize with a process like this increase sprint throughput?

  5. What labels might be useful for your team? e.g. morale, velocity, security...

We can help

Stepsize works with organisations like yours to make the most out of your engineering resources and manage tech risk better

PreviousTalking to your Head of Engineering about StepsizeNextUsing Stepsize in your planning process

Last updated 2 years ago

Using the Visualisation tool in Stepsize

🤙

👥
Set up a call with us