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:

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.

US Digital Services Playbook – 13 Plays for Better Project Success

Recognizing that the delivery of digital services within the Federal space is often over budget, over schedule, or simply do not work well, the government has developed a ‘playbook’ that describes 13 plays that can help to improve the delivery of solutions.  (Note:  These are appropriate for non-government projects as well.)