Confusion over measuring Value (Pt 3)

3rd part in a series regarding story points and value

My earlier post here, I introduce us to the phenomenon of the Federal customer requiring a story point quota per sprint or release, in part, as a measure of progress/value delivery; and a brief overview of story points.  My previous post here, tries to make the point that value measurement is hard, and that story points and velocity is best suited for the calibration of the team and how they operate within the ‘system’ that is creating value, not the amount of value delivered.  Now, I will attempt to draw a few conclusions in this post.

Ultimately, the goal of building these software solutions is to provide something of value to the customer.  Mark Schwarz, the former CIO at USCIS, posted a blog on LinkedIn related to the notion of using BI to evaluate the ‘value’ delivered since the stories, points, velocity are all leading indicators to the ultimate trailing indicator, of outcomes delivered.  Mark’s Post on LinkedIn.

Do Story Points = Value? (Pt 2)

2nd in a series of posts related to story points and value delivery

The TechFar Handbook suggests that the Government should be intimately involved with the Agile process:

As part of its responsibility, the Government is involved, at a minimum, at critical decision points in each sprint cycle – at the requirements development phase and sprint cycle review, but it is preferable to have daily involvement from the Government Product Owner, and frequent involvement from end-user representatives.

Essentially, the Government should be involved in the prioritization of the backlogs, the release and sprint planning events, and at the sprint and release reviews.  This is in alignment with the Agile Manifesto that states that we value, ” Working software over comprehensive documentation”; and the related principle “Working software is the primary measure of progress”.

Story Points – A measure of progress? (Pt 1)

Alarming trend to establish story point quotas...

This is the first of a series of posts I’m working on related to the big idea of Story Points, tracking project progress, judging value, and a myriad of related issues.  For instance, I’m aware of three active agile government projects that each has a strong desire to use story point production (or a similar valuation) as a measure of progress and base payment on that progress per sprint or product increment (release).  This isn’t to say that is good or bad, contractually right or wrong; rather, I want to explore this need of the customer to evaluate progress and value.  But first, an introduction to Story Points:

SAFe is complex, just look at the diagram…

Don't fall into the trap.

I was inspired by a post on LinkedIn by Mike MacIsaac titled “The problem with scaled Agile and SAFe” so I took my comment and create this blog post from it.  In a nutshell, the author was relating that the SAFe BigPicture diagram is complex; therefore, SAFe is overly complex and the true meaning/concept of Agile is lost.  I think many fall into this ‘SAFe is too complex and burdensome, just look at this diagram’ trap without really trying to understand what it represents.

Entrepreneurial

The secret ingredient to an Agile/Lean Enterprise?

I was reading the report from the Learning Consortium that is associated with the Scrum Alliance and Stephen Denning, and what I liked about the report is that it was not religious about Scrum, or Kanban, or SAFe, or any of the common jargon regarding Agile/Lean organizations.  Rather, it emphasized entrepreneurialism.

Get some light on your Backlog

Dangers embedding technical details in User Stories

Hindsight is always 20/20, but it was clear something wasn’t right.  For months, a small ‘specialist’ team spent many hours a day, for weeks/months, architecting, designing, thinking, debating, and controlling the scope of work.  To the point that only a trickle of information ever escaped to the larger community, and that info that did escape was simply to provide something for them to work on.  The goal was to create ‘The Backlog’ for all to consume.

User story chaos

Let Story Mapping bring some order to the chaos.

The concept is so darn simple, it is a shame that it is not more prevalent.   Struggling with seeing the big picture for your product or solution?  Do you have user story explosion and it is difficult to see the roadmap and big picture?  Afraid you are missing something?  Backlog gold plating going on? Arguing about features, or worse technical implementation details related to features or stories?

Your Agile Project is off to a challenging start when…

[su_dropcap]OK[/su_dropcap] – this isn’t the post your were probably looking for, but I had to point this one out.  On a project I was supporting, there was much debate and consternation, not only about the solution itself, but an almost all consuming debate and discussion regarding the structure or hierarchy of the Product Backlog Items across the relevant Backlogs.

Value proposition with Agile

Avoid value atrophy with short releases

How does Value survive over Time?

I have found it difficult to describe the Agile pay off, or value proposition when introducing Agile.  Perhaps your audience is aware of agile, maybe even attempting a few agile projects.  But how do you describe the value proposition?  Is it faster time to market? …True but not the entire scope initially.  Is it higher quality? …quite possible.  Is it more transparency? …sure but we have lots of meetings already.  Is it Customer Delight? … Perhaps, but how do you measure that?