The Governor of Agile - User Stories

In Agile, a user story is a set of words that communicates a software feature from an end-users perspective. And that's an important distinction, it's from the end users perspective, in layman's terms, not some gobbledegook verse from a technical person trying to translate from real world to computer world.  This is an enlightening aspect of Agile, that engineers don't need gobbledegook, they do better with the customer voice. 

User stories are accumulated in a 'back log', a list of stories to be prioritized in 'back log grooming' meetings by Product Management, then estimated by the development team, and finally assigned to a sprint where they are actually implemented by the team.  User stories are the fuel that runs agile, without user stories there is nothing for Product Managers to groom, nothing for developers and QA to estimate and nothing for the team to implement and deliver, there is no fuel for the engine.  Many times user stories become the Governor of the velocity of the team, or how fast the team can produce, without enough user stories the velocity is less than optimal or in some cases I have seen zero, yes developers actually 'sitting on their hands' doing nothing. 

So if you are embarking on or are implementing an Agile development process pay close  attention to the fuel of your scrum, the user stories.  Who is writing them, refining them, breaking them up into smaller stories that can be more accurately estimated?  This can be your weakest link.

Perfect Process Doesn't Always Make Perfect Product

Agile is the evolutionary equivalent of the Neanderthal in human evolution, not quite perfect but sustainable.  This evolutionary milestone is a testament to the state of modern application and collaboration technology. We now have the tools to enable self organizing  cross-functional teams  to collaborate on requirements and solutions.  Tools like Slack, Confluence, Trello provide the collaboration channels these teams can use to follow the Agile process.  The Agile process is an iterative development process, where requirements and solutions evolve efficiently through collaboration and realignment, and each iteration delivers shippable product.

Early morning scrum meetings, sprints, backlog grooming, planning, estimation, demo and post mortem's the process is well defined but flexible.  But sometimes the process becomes the 'finger pointing at the moon' the team becomes more focused on the process than the product.  This is especially true of teams that don't follow and learn from their product as it is shipped into the market, as an MVP or simply a new version.  Without a feedback loop a system or process can't adjust it's performance to meet the desired output, or what the customer really wants, it just keeps putting out ... well stuff.  I have seen more than one highly efficient agile team follow an optimized process and produce bits that no one ever used, and it's a shame, customer feedback would have changed everything.  Spend more time looking at the product and not the process.