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:

Policy Loans for Investing

Leverage your Policy Loan for better returns

The following is a SketchNote (‘SketchNote Handbook‘).  Basically a graphical notes page that describes an IBC policy loan example used to make an investment.  In this case, the investment is $50k for an apartment complex deal where the returns should be considerably higher than the guaranteed returns on your cash value, and considerably higher than the interest rate on your policy loan.

Go to Bread Recipe

Super easy, bread recipe

Ever wish you could make some fresh bread without a lot of work?  I stumbled on this recipe from Instructables a couple years ago and have never been dissapointed.   Check it out here:

http://www.instructables.com/id/4-Hour-No-Knead-bread/

The 4-hour No Knead Bread recipe works just as is, but I do have a few modifications that I’ve found that I like to add to the recipe.

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.

What’s your savings rate?

Arguably, the most important piece to the retiring comfortably puzzle

If I’ve read it once, I’ve seen it 10 times across a variety of blogs and newsletters.  Sure, making 12% consistently on your stock picks or investments in general will definitely help; but, if the ratio between your savings rate and expense rate is favoring your expenses, you are fighting a losing battle.

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.