Best products from r/agile

We found 56 comments on r/agile discussing the most recommended products. We ran sentiment analysis on each of these comments to determine how redditors feel about different products. We found 71 products and ranked them based on the amount of positive reactions they received. Here are the top 20.

Top comments mentioning products on r/agile:

u/J19Z7 · 19 pointsr/agile

>Is there a book/video/training that can give me a really solid understanding of expectations of Agile?

Many. You can spend thousands of dollars and attend hundreds of hours of training. Scrum.org and ScrumAlliance.org both offer certification classes. But that is not what you need at first (unless the company pays, then do it!). The first thing you need is to understand agile is an adjective. You can look up the definition in the dictionary. If you use google though, look at the traditional definition "able to move quickly and easily", not the "project management" bullshit. Agile is not project management. Dictionary definitions are what is in common use, not what is correct, and there are a LOT of traditional managers and PMO "gurus" misusing the term. Agile is about your team/org being agile: responding to the constantly changing project & world quickly & easily.

​

Next, read the agile manifesto. The manifesto is the basic description of what the creators identified as the shared reasons their individually designed practices were successful. The actual processes they created were all customized to the creator's individual teams and situations. They all had different ways of doing things, but realized they were all successful because they all valued, for example, "Individuals and interactions over processes and tools".

​

Now, get ready to fight the PMO. I say "fight" a little facetiously though, because remember the one value I listed above? VALUE individuals and interactions. If you're "fighting", then you're not interacting very well. If management and their PMO are not on board though, you're going to have a fun time trying to merge stuff because you're going to be violating principles left & right just because they have the authority to beat you up if don't follow their processes.

​

I haven't really answered your questions yet, have I? That is because the questions you asked are a little advanced. How do you merge what the agile frameworks are recommending with management & PMO's processes, needs, and expectations? By talking with your org. By training them in the "agile metrics" and how to use them. By getting their support for the agile transition. By setting up many intermediary steps to get them comfortable and familiar with the new way of doing things. By showing them how successful one high performing team can be, and then describing the compounding benefits of getting the entire org on board so you can do that. This is stuff an experienced agile coach can help walk your org through over time.

​

So how about a couple solid answers of varying worth to your specific questions/comments?

  1. "IT infrastructure is transitioning to Agile/DevOps." No they aren't. Not really. The "Dev" in "DevOps" is "Developer". The entire point of that portmanteau is to describe the merging of development & operations teams, to eliminate the problems associated with handing off the developer's work to infrastructure to install & manage. If you want a quick, semi-fun fiction style read about this, try The Phoenix Project.
  2. "from what I have been reading, it sounds like I shouldn't be using both methodologies, but I am getting pressure from both sides to do so." It is very difficult, as I alluded to, but is not impossible. If the org is really going agile, there are going to be huge changes at the start. If not, just don't worry about it. Do whatever process they want and take it as yet another process you've "learned", without the backing values. Without management's support actually adopting the agile values, it is not a fight worth having from the trenches.
  3. "How can I provide end deliverable dates if we are living in an Agile framework." To start, pretty much the same way you're doing things now. Sum up the estimates for all the pieces, and that is the estimate for the project. This isn't ideal and you're going to have issues. Work through them as they come up. 😀
  4. "Should/Can I be an effective Scrum Master if I am not a developer?" Absolutely. Scrum separates the roles. In your position I'd be more worried about separating the product owner & scrum master roles. That is where you're going to get pulled in different directions. The product owner has the vision for the product, they decide & communicate to the team what to build. The scrum master is there to help the team improve their practices: identify & remove impediments, train on new practices, ensure teams are talking & healthy, etc. Finally, it is the developer's self-organizing cross-functional skills everybody must trust to get the project done... They will decide the how. Read Coaching Agile Teams, by Lyssa Adkins. As a project manager transitioning, I guarantee that book is right up your alley. That is the transition she made and can help you make. That will help you get on the right page as a scrum master.
  5. Read whatever framework the "project" (i.e., "agile" team) is going to use (scrum, right?) They tend to be short. Just know it's a framework. It is designed for you to fill in all the gaps according to what you identified as your needs.
  6. "Sorry I feel like I am all over the place, but it is indicative of what I am facing at work." Ya, sure sounds like it. Agile stuff is fun if you have the right Abundance Mindset.
u/Triabolical_ · 1 pointr/agile

Pro tip. If you find yourself talking about "getting people on board", you are taking the wrong approach; you are thinking about how to make your life better rather than how to make the overall organization better.

I can tell you what you are going to get out of your approach:

  1. You will get resistance from the people proposing features because you are asking them to do extra work to make your life easier. Whether you get agreement or not is going to depend on the politics of the situation.
  2. You will see a wide variance in the quality of the descriptions that you get, because a) the customers don't really know what they want and b) they aren't very skilled at expressing what they want.
  3. You will get proposals with details that contradict the expressed direction that you want to take the product, details that are don't make sense, and details that violate known laws of physics.
  4. The details you get will age poorly; they will refer to other feature that got cut or that got changed significantly during design.
  5. Some of these features will get cut.
  6. Even if you get perfect details, they will be insufficient for the dev team to go off and do the implementation, and you'll need to talk with the requester anyway.

    I see two big violation of agile principles in what you are proposing:

  • We want to minimize the amount of work in progress that we have. All of those details are work in progress, and much of that work will be thrown away.
  • We value individuals and interactions over processes and tools.

    A relevant definition here: "A user story is a promise to have a conversation". When you pull that request as something you are going to work on soon/right now, that's a perfect time to have a conversation between the development team and the user who requested the feature. In an hour you can discover the majority of the details that you need to do the implementation, and it's efficient both for your time and for the user's time.

    > Lastly, I'm really curious as to how people are valuating the value and cost of a task. How do we, as a development team, map out the technical cost of a feature and how should we ask the business to map out the value of getting a requested feature?

    This question comes up often, and here's how I like to think about it...

    For a given set of feature requests, there is an ordering that maximizes the benefit and minimizes the cost. You can probably come pretty close to determining that ordering for the top 25 items if you take the 15 people involved and lock them in a conference room for a week, so that is obviously the optimal approach, right?

    Having once spent 3 weeks of my life costing in a room costing and ordering a multi-year backlog, I can assure you the answer is "no".

    The problem is that an important question is missed, and that question is, "what is the opportunity cost of having long discussions about the exact ordering?"

    Given that such discussions typically involve senior stakeholders and they all have much better things to do with their time, the opportunity cost is high.

    What you should do is ask the requesters to bucket the requests into low/medium/high value, and you should do a really quick sizing estimate of small/medium/large/extra large for implementation effort. Then you just do a simple sort, and the list will be fine in most cases, and all you have to do is discuss where it isn't, move a few things down, and you're done.


    I agree strongly that you need an agile coach; not only to help you with these things but to help have some of the conversations you need to be having across the organization. I also highly recommend a couple of books to you:

    Ron Jeffries has a nice book called, "the Nature of Software Development", which is a great short introduction about agile development. It's short enough that you can hand it around to people.

    "The Phoenix Project" is a book about apply a lean technique called "The theory of constraints" to software. It's a novel and a pretty quick read, and the reason I recommend it is that it takes a "whole organization" perspective rather than focusing in on the dev team. It is essentially an adaption/rewrite of a lean classic called "The Goal".



u/frazaga962 · 1 pointr/agile

I apologize in advance for the long post: Thanks so much for all the help and feedback everyone! I will definitely try to utilize everyone's advice as best I can. Here is my game plan for the next few months. I would love more feedback if everyone is willing to help refine my process.


1- After talking to my aunt/mentor in the field, she recommends that I should not go for the CSM *until* I have a working understanding of the field I will be getting into. She recommends that I apply/learn as much as I can about Project Management Essentials like the one she took in UChicago. Unfortunately, the next class that is offered is Jan 16th, and I personally want to leave the hell that is my job as soon as possible.

To get over this, I have decided to learn as much as I can on my own from books like A, B, C, D, E (please take a look at recommend if there are others I should look into or if I should drop any). She recommends that I do not focus on just Agile but also Waterfall (a basic understanding). I will also be utilizing the podcasts and links graciously provided by u/recycledcoder:

"So... podcasts. There are many, but these are my faves:

  • Agile for humans
  • Scrum Master Toolbox
  • Agile uprising

    And finally, my own preferred twist on it all: Modern Agile"


    2- Once I have done as much research on the fundamentals as I can before October 13 (not a lot of time, I know), I will be attempting the CSM boot-camp course. I want to do this because I have no prior experience in field, and while I know a certification may not mean much, I hope it reflects my desire to start applying for roles for project coordinator positions. I will have to tweak my resume to show my desire, and I think the certification is the first step to do this. I'm favoring the CSM over the PSM and PSPO per u/nizzerp and my aunt's advice as these courses need more experience to apply for.

    ​

  1. I know several technical recruiters and I think the best step for now would be for me to reach out to them (thanks u/zappafield) and see what temporary/contract positions I can build up in the meantime. I think that with enough short term positions in different environments I will be able to best get a full scope of the field I am getting into.

    ​

  2. While I am still stuck in the hell of trying to get a company to let me on a/any project, I will be going on meetup.com (thanks u/Curtis_75706 and u/zappafield for the idea) to better immerse myself in what I am hoping to get into. Also will be trying to bolster my credentials with MOOCs (per u/kmolch) with any recommendations you wonderful people may have. I am definitely interested in the Business Analysis route they had mentioned.

    ​

    I know there are a lot of links and stuff, but I would really appreciate it if I could get as much feedback as I can to start committing to this plan, especially feedback on books and resources in my step 1.
u/CMFETCU · 2 pointsr/agile

To gather insight, help teams find their own places they want to improve, and generate self-realized learning... try Agile Retrospectives: Making Good Teams Great.

Consensus driving change or driving work is all about figuring out what is the next best thing to try and improve.

If you aren't already, try capturing the outputs of your retros and have the team commit to one thing you want to make better or make great. Make this an actual backlog item and track it as you would work coming in. It should be owned by everyone, and it should be a driving force to try some actions to improve it. If you can get 1 thing agreed to by the team to improve, and then a proposed action to try as a team; you will rapidly find your pain points and make them better.

u/gracebatmonkey · 6 pointsr/agile

Before anything else, there's a great book that helps with this whole thing: Agile Estimating and Planning

Next, there are lots of other approaches, and based on how you're explaining your understanding on the three methods you offered (and the benchmark example especially), I think you might find some clarity in reading through these resources:

8 Agile Estimation Techniques Beyond Planning Poker - I think this will help the team wrap their heads around what's being asked in expressing estimates with storypoints.

Fast Estimation - really good technique that cuts through the noise.

Agile Project Estimation Techniques from PMI- because of your questions relating to release intervals, I think reading through this article that goes into detail about some of the techniques already mentioned may simplify your thinking on this, especially the section on "Determining Budget".


Finally, answers to your specific questions:

  1. Yes, I worked with a team that did this. They had a good understanding of the needs of their qa team and were conscientious about documentation and smooth code review protocol, so that helped a lot. If something would take more than the available hours in a sprint, they'd break it down further to discrete work parts. They did move away from it after they had a better concept of capacity and velocity as expressed in story points. I think they were an exception, rather than the rule, however, and for most any other team I'd likely recommend entirely different approaches, since it's easy to get bogged down in the translation.

  2. You would take a new benchmark story. Partly because as the team gets more mature, something estimated at 3pts at one point in time would now maybe be 2, and partly because effort needs to be evaluated in context, so an older work item would have staled in relevance.

  3. This is more of a learning to estimate technique than one that would stay in the team's toolbox forever, maybe to get pulled out again in the future to break down particularly sticky specs/reqs. At least one of the articles above discusses this method in detail, perhaps making it easier to decide if it's worth using.
u/MisterFuFu · 2 pointsr/agile

Some additional information can help a lot in recommendations. I'd like to know the following:

What is your team size?

Is your team co-located (all in one place)?

Can you describe the type and flow of your work?

Do you have open channels of communication with your customer, and if not, do you have people who can stand in and more or less speak for the customer?

Do you think the leadership would be on board for a drastic change?

It is unlikely that the visibility and continuous improvement of an agile framework will not bring about significant improvements within your company. Also, if you are the type that thrives on facilitating a team and helping them grow to excellence, then this will be a great career change. Personally, I love my job and enjoy every day. With the above simple questions answered, it would be a lot easier to spark a conversation.

Jeff Southerland's book (already mentioned) is a great intro for Scrum, and not a boring read. I also like David Anderson's Kanban, if you have a more steady continuous workflow like a compliance or support team, this can fit better. Also, a good read. The Scrum Guide is rather short and is the definitive guide for the Scrum framework. Exactly how you execute under that framework is largely up to the team, but everything is based on the idea of iterative continuous improvement. Once you get this idea down in practice, you'll be hooked.

u/sm-ash- · 3 pointsr/agile

The role of the product owner is a little tricky because there isn't a lot in the scrum guide that tells you how to do the tasks required. A lot of these tasks happen outside the sprint and touch on Agile Project (or product) Management and lives in the realm of Business Analysis. Of course communication with an emphasis on listening carefully is going to be the key skill.

Requirements analysis or requirements engineering is the process that you seem to be looking to define. Searching on either of those terms may prove better results for templates or techniques. That's the process of determining the user needs / wants / expectations and turning those into features.

The first step that I find important is to ensure that the PO has a clear vision of the product. By this I don't mean the details of how it will function but what is the domain the product lives in and what problems it's trying to solve, basically the why of the product.

There are several techniques that can help to define this. Some people like the Business model canvas or the lean canvas filling those even partially with stakeholders can help to define the vision.

Another technique is a version of the Product Box Game that you can do with your stakeholders to help define the features of the product. Imagine what emotional is portrayed by the box's artwork and what features are prominent on the front, what secondary features are detailed on the back.

Books that may assist are User story mapping and the techniques described in there are basically what SCRUM requires.

In the past I have also used some of the techniques in the Rational Unified Process to get a sense of the types of questions that should be asked. I don't want to put too much emphasis on that because I really don't recommend following RUP because it's way too bloated (way more than SCRUM) however, one could easily skim some of those such as the Elicit Stakeholder Requests or the idea of Capturing a Common Vocabulary can be helpful as some people use terms very differently. I don't really want to link to that because I really don't recommend that process but if someone asks I'll link it.

TL;DR check out this video, Product Owner in a Nutshell





u/Onisake · 1 pointr/agile

Agile doesn't make much sense in this context. This is an oversimplification, but Agile is essentially applying lean to software development.

Overs simplifying again: for the most part software development as a whole doesn't understand software development. IE: what are the basics of software development. what does good development look like? what are best practices? etc.

When working in manufacturing and going lean, you generally start with Just In Time manufacturing. For lean development you begin with the iteration. Scrum acts as training wheels because it encompasses the basics of Agile in one nice neat little package. you are, however, expected to iterate against scrum to become Agile.

HR, Finance, and other organizational functions don't generally have development projects. As such, i'm not sure how well it applies or what you would even iterate through.

You're probably better off looking up and learning about lean. it's kinda the same thing but likely more applicable to what you're doing. IE: Lean Project Management. or Lean Program Management. Here's a book on the topic: https://www.amazon.com/Agile-Lean-Program-Management-Collaboration/dp/1943487073

u/CaptainKabob · 3 pointsr/agile

That sounds tricky. I think you're starting with the right place: visualizing workflow;

A suggestion is that you focus on building trust by addressing pain points. What pains does the team have with the current process and can you concretely improve those in the short run (as opposed to abstractly saying "if we adopt this whole enchilada that will get better, trust me").

Another thing to focus on is measuring some of the health indicators in Accelerate. Honestly, you might be doing awesome already and the problem to be solved is recognizing and celebrating it. Good luck!

u/Dayleryn · 2 pointsr/agile

Your approach is quite interesting and brings a lot of questions and impressions, so kudos for sharing your thoughts!

> One question I have with this approach is at what point is something considered a complete "feature" and should thus produce a velocity point each iteration?

Simply put, when the "feature"'s Definition of Done is satisfied. If you have trouble defining a DoD for certain feature types, then these types might need to be clarified and/or downsized.

> What is a better name for this metric than velocity?

"Added value" seems right, considering you subtract from that metric whenever value-decreasing elements such as bugs and errors are discovered.

Now, my first concern with your approach is, like I started this reply with, that it brings a lot of questions... too many for me to consider this approach viable in the longer term.

First, such a composite metric fuses so many different variables that correlations will become undetectable... unless you measure these variables separately, which will make the composite metric irrelevant. For instance, say your "added value" suffered from an unexpected drop for a few days, one month ago. Based on your musings, this could be correlated with an acute lack of QA, a few developers on vacation, an exceptional hardware error causing hundreds of errors to be logged... anything, really. Therefore, if your metric doesn't help you investigate root causes, how will it be useful to your team?

Second, your rules related to bugs and errors make the wrongful assumption that all bugs and errors have the same impact, share the same priority and diminish your software's value equally. If your metric came to be used by management for evaluation purposes, it wouldn't fair for your team to be penalized the same for a production-crashing bug than for a typo in an administration console.

Finally, from the way you describe the metric's heuristics and their evolution, I'm afraid you'll be tempted to spend significant effort tweaking these heuristics further... that could be invested in investigating bottlenecks, researching testing tools, refining your features' Definitions of Ready and Done, etc. Say your added value is impacted way more than you expected by bugs and errors: will you consider adjusting them to -1 added value points by 5 hours of non-resolution rather than 3? Or perhaps only certain types of bugs and errors should cause these losses? What about higher-value features that could provide more than 1 added value point? Worst of all: as soon as you make one of these tweaks, your metric's past values will no longer be comparable to the revised values and your historical data will become near useless.

If you are interested by alternative approaches differing from Story Points and traditional hourly estimates, I have learned much from The Scrumban Revolution and Actionable Agile Metrics from Predicability; applying their knowledge to my previously-Scrum team brought us many benefits and improved productivity. Hope these can help you as much in return!

u/shaziro · 0 pointsr/agile

> By the way: scrum does not assume deadlines. They refined their wording from commitment to forecast in 2011 to make it clear that the sprint output is not based on a fixed scope.

Scrum can be done with or without deadlines. The scrum framework does not say that there should or should not be deadlines. The fact that we are forecasting does not mean that we are unable to do deadlines. It just means that we should not be accountable for getting the work done in the time we predict it will be done by because we know that work can take longer than predicted. This is why Essential Scrum proposes fixed date releases with negotiable scope.

>At the end of the sprint, it is important to have a potentially shippable solution. It is ignorant to assume that your sprints content will be done completely. If we would apply math, we would realize that missing the sprint forecast should be the normal state.

I did not say sprint contents should always be done completely. In fact, I agree that it should not always be done completely. Mike Cohn, author of Agile Estimation and Planning, recommends to complete everything that was pulled into the sprint 80% of the time. I don't see what this has to do with deadlines.

>Estimation has the same issue: we are not interested into having a number like "it takes 12h". We are interested into knowing what needs to be done and want the ability to roughly predict the future. As such maybe terms like sizing or task breakdown are better wording.

Isn't sizing some form of estimating? If one user story is a 2 and another user story is a 4, we are estimating that one of the user stories is twice as complex as the other. We don't know that it will actually be twice as complex until we get down to working on it.

u/shermanlbc · 1 pointr/agile

I'm a big fan of The Great ScrumMaster by Zuzi Sochova. Zuzi is a good friend of mine and has traveled the world professing Scrum - she is a board member of Scrum Alliance.

The Great ScrumMaster: #ScrumMasterWay (Addison-Wesley Signature Series (Cohn))
by Amazon.com
Learn more: https://www.amazon.com/dp/013465711X/ref=cm_sw_em_r_mt_dp_U_qr1lDbQZ74K1E

u/AgileStash · 1 pointr/agile

Here you can find some recommendations: https://agilestash.com/books.html

Apart from the ones in the website above, I'd like to recommend to you as well:

u/thanassisBantios · 3 pointsr/agile

Hello! Have you read Esther Derby's "Agile retrospectives"?

https://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649

It provides a good explanation of all the retrospective stages, as well as activities to do for each stage (in your case, the "gather data" stage). Or you could try some activities like those described in funretrospectives.com

Having said that, sometimes it is just better to talk than write. I do many of my retros on a cafeteria outside where we all sit in a table (12 people). The format is simple, no writing, we just talk one after the other (or just begin a conversation) to collect our memories and problems form the previous sprint. It is amazing how powerful that is.

u/randallnothopkirk · 1 pointr/agile

Manifesto here..

http://agilemanifesto.org not the finest looking site but key points covered.

https://www.scrum.org good place to start, scrum is just a flavour of Agile

Main thing though is mindset, once people buy in it becomes much easier

Scrum - A Pocket Guide (Best Practice (Van Haren Publishing)) - place to start Scrum dive

and I like this one https://www.amazon.co.uk/dp/B00UOYB2N6/

u/cybernd · 4 pointsr/agile

Book recommendation: https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339

This book is not directly related to agile. But it is rather unique, because it is based on studies and not on authors subjective opinion. It tries to figure out, which mechanics are relevant for modern software development teams.

Most often our rituals are not based on evidence. They are originally based on convenience and afterwards kept up as dogma. Sadly the original introduction was often done by the wrong people.

For example agile was mostly invented by developers, but the widespread adoption of scrum was done by business people (managers as scrum master). As such a dogma was formed that may not be in the best interest of solid software engineering.

u/nostradamnit · 5 pointsr/agile

If you are interested in Scrum, I'd recommend reading Software in 30 days and/or Scrum, the art of doing twice the work in half the time or at the very least, read the Scrum Guide. For agile in a larger sense, there are plenty of good books, like The Art of Agile Development or Agile with GUTS

u/Euphoricus · 3 pointsr/agile

I'm no statistician, but I find it hard to accept you managed to get statistically significant results from just single (1) (one) sample.

There is of course proper study that links technical and management practices to business outcomes and finds statistically significant correlations between them. See : https://services.google.com/fh/files/misc/state-of-devops-2019.pdf and companion book https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339

u/adshad · 3 pointsr/agile

I would recommend Reinventing organizations by Frederic Laloux.

Lots of good examples in many different business domains (nursing, auto-parts manufacturing, clothing) and basically doesn't mention software development.

u/stray_coder · 1 pointr/agile

Jeff Sutherland's book Agile: The Art of Doing Twice the Work in Half the Time is a great read for anyone that hasn't practiced Agile.

http://www.amazon.com/Scrum-Doing-Twice-Work-Half/dp/038534645X

u/Deespicable · 2 pointsr/agile

Oh interesting, I was going to wait until this book is out. It was recommended by Mike Cohn
https://smile.amazon.com/dp/1449314333/ref=olp_product_details?_encoding=UTF8&me=

I'll take a look at the book you mentioned

u/Iammyownmaster · 2 pointsr/agile

Coaching agile teams is amazing. Once you understand the scrum processes read this book. Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition https://www.amazon.ca/dp/0321637704/ref=cm_sw_r_cp_api_i_yRv3DbZ9B4YY5

u/dkode80 · 3 pointsr/agile

Can't express how good this one is. Overall, any of Mike cohn' books are all great

https://www.amazon.com/dp/0131479415/ref=cm_sw_r_cp_awdb_t1_scbOAbVTE20NV

Edit: user stories applied is another one of his greats:

https://www.amazon.com/dp/0321205685/ref=cm_sw_r_cp_awdb_t1_WdbOAbZP5TPTC

u/iawia · 5 pointsr/agile

Jeff Patton's Story Mapping, even though it seems more limited from the title, is probably the best introduction on _how_ to do the job.

u/clem82 · 1 pointr/agile

Pens and post its work.


This book gives you hundreds of actionable opportunities based on the audience: https://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649

u/daqm · 1 pointr/agile

I reccomend that you read this and follow his blog too, he's written extensively for this subject amongst others

User Stories Applied: For Agile Software Development (Addison-Wesley Signature) https://www.amazon.co.uk/dp/0321205685/ref=cm_sw_r_cp_apa_i_09mQCb22J357P

u/euclid223 · 2 pointsr/agile

Scuse my ignorance... What does OM mean? 😁 But yes, we're trying to optimise for overall flow of customer value. The other metrics account for "de-risk deployments by doing it a lot", "don't break production" and "if you do fix it quickly". These are not of our own design by the way... Completely plagiarised from https://www.amazon.co.uk/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339

The overhead for measuring feature lead time is minimal thankfully. I put a label such 'value-marker-1' against the first and last stories in a Jira epic. A new valuable thing inside an epic just means I increment the number on the labels I use. Also means you can have measure multiple valuable things in an epic with overlapping timelines. My cronjob gathers this up daily along with a bunch of other metric information. I owe a detailed blog post to https://medium.com/onzo-tech by the end of March.

We're seeing a healthy tension across the route numbers and it looks hard to game one without sacrificing elsewhere. I am measuring deployment leadtime too but haven't set a target there as I can see it leading to bad behaviour. One thing I am currently wary of is the short term temptation to reduce technical quality in return for lower leadtime. It would eventually manifest in higher change failure rate and increasing lead times