How to write a good user story.

Tell a story and get work done. 

When you are working as a scrum master or agile coach, your biggest challenge is getting others to understand the concepts of agile.  It is like teaching young children to read.  The concepts seem natural to an adult, but to a six-year-old, it is an alien skill to master.  It occurred to me this week I have written numerous blogs about the different aspects of agile development, but I have never written a blog about authoring user stories.  Today, I want to change that oversight.

Let me begin by saying I am sharing with you how I teach others to write stories.  Each coach and each environment is different.  Feel free to treat this blog as an informed suggestion of how you can do things at your organization.

In the early days of agile, a user story could fit on a post-it note.  Team members would see the story ask the product owner for some discussion about what to do and then the work would get done.  The early approach assumed the development team was in the same room and the product owner was always available to answer questions.  Today with team members scattered around the globe, product owners focusing on customers, and countless tools to track work items, it is not realistic to rely on just post-it notes.  Regardless of what system you use to track user stories, the first thing you should do is boil the work down to one sentence.  I use the following format.

As X I want/Need Y because of Z.

The template is easy to follow and works in most situations.  Here are two examples.

Example #1 – As a sales manager I want the background of the shopping cart page to be blue because it reduces the number of dropped shopping carts.

Example #2 – As a user, I would like the website to save my customer information because I do not want to retype information. 

In both examples, the subject of the sentence is the person who needs the work done.  The predicate of the sentence is the actual work.  The modifying clause is a credible reason why the work needs to get done.  The sentence should satisfy the Who, What, Where and Why of the work.  It is up to the developers to provide a credible answer to When the work gets done.

Once you have authored a user story, it needs acceptance criteria.  Acceptance criteria are important because it removes misunderstanding between a member of the development team and the product owner.  Unlike waterfall techniques which demand long and confusing narratives, I show product owners the Gherkin or Given, When, Then (GWT) formatting of writing acceptance criteria.

Given: I am registered user of the website
When: I check out my shopping cart
Then: My billing information is retrieved
And: My shipping information is retrieved.

Notice the GWT does not say how to do the work; it just says what the product owner expects the development team to deliver.  The team could use session variables, cache objects, or cookies to do the work.  It does not matter.

A user story should look like this in the work item tracking system.

23 – Save shipping and billing info
As a user, I would like the website to save my customer information because I do not want to retype information.
23.01 
Given: I am registered user of the website
When: I check out my shopping cart
Then: My billing information is retrieved
And: My shipping information is retrieved.

The number is usually automatically generated by the item tracking system.  I use a ##.0# numbering system for acceptance criteria for clarity, and I provide a title for stories.  During stand-up meetings, developers refer to stories by saying, “I am working on number 23 save shipping and billing info.”

I hope this is a good starting point for how to write user stories.  With practice, it will become natural just like reading.

Until next time.

Transform at the speed of the Team

Coaching is more than presentations.

Software development is not rocket science; it is a branch of engineering but, it is not rocket science.  I say that because rocker science depends on the laws of chemistry and physics which have not changed since the big bang.  Software development is changing daily.  Javascript libraries are constantly being updated and going in and out of fashion.  Versions of PHP change and open source code is in constant flux.  Finally, software development is dependent on the fickle demands of consumers who use it.  The level of chaos and change are staggering.  It is why software development is such a challenging profession.  As a scrum master and coach, you must understand those challenges and guide development teams through the process.

One of my favorite pieces of journalism is Bloomberg’s weighty essay entitled “What is Code?” It talks about the person in the taupe blazer and the frustrations of software developers.  It also does a great job talking about the headaches the executives who manage software developer face.  The essay captures perfectly how smart people struggle daily to get dumb machines to act intelligently.

The world of software has tremendous power, but that power belongs in a small subset of the world population.  I calculated that less than .05% of the global population of 7.4 billion could maintain software and computer networks.  Many of these individuals work in the quiet recesses of government and business keeping things running.  They go home to families and friends.  They pay bills and try to live their lives as best they can.

Because of the laws of supply and demand, computer professionals receive large compensation, but the compensation comes with a trade-off.  The trade-off is long hours on uncompensated overtime and business leaders expecting them to perform magic.  It creates conditions which lead to poor quality and burn out.  I have experienced this situation as a developer and as a manager.  As a customer, I have stumbled on numerous situations where fatigue, complexity, and unrealistic expectations have combined into a poor product.  The history of the internet contains plenty of companies which had a few pixels and an unhealthy dose of hype.

Technology professionals have lived in that world since the early 1990s, and you can excuse them for being suspicious of new approaches to doing things.  For every Amazon.com there are hundreds of companies like Pets.com.  So bringing ideas like Test Driven Development, S.O.L.I.D. programming and Agile is going to face resistance.  As a scrum master or coach, I recommend you begin slowly introducing concepts letting people test out an idea to get comfortable with them.  It also helps if you understand and recognize the pressures the team faces.  Are they distracted by requests which are urgent but not important?  Do you have a healthy cadre of product owners or is the role being performed by a manager?  Finally, are they working with a brittle technology stack? Answering those questions will determine how fast you can go during your agile transformation.

Software development is not rocket science.  It is a challenging field prone to error and burn-out.  Only by paying attention to individual challenges each software development team faces can they be coached into an agile way of doing things.

Crazy little thing called Jira

Old School Scrum board.

As an agile coach, I have learned to consult the agile manifesto whenever I get stuck on how to proceed.  When I changed firms, I moved from a company which used Azure DevOps to one which used Jira.  It was a bit of a shock.  Fortunately, after working with the tool and reading the book “Agile Software Development with Jira,” I feel comfortable enough to work in a busy software shop which uses Jira.  The experience gives me additional insight into the differences between the two tools.  I want to talk about that insight this week on the blog.

Before I begin, it is necessary to have full disclosure. I have spent a majority of my career working with Microsoft products.  In 2008, I made the switch from Visual Source Safe 2005 to Team Foundation Server.  I have worked with the tool as it has grown and changed into its current incarnation Azure DevOps.  I also know members of the DevOps “Blackshirts,” at Microsoft and one of my mentors for the last ten years in this business runs a blog called “The TFS Whisperer." In short, I have a serious professional and cognitive bias toward Azure DevOps.  I have even authored a blog defending TFS from a blogger who considered it “destroying development capacity.”  If I were the CIO at a company, I would prefer Azure DevOps vs. Jira.

Now that I have confessed my bias, I am going to attempt to set it aside and try to compare the tools.  The first thing which sticks out to me about Jira is the ability to configure it.  When you create a project in Azure DevOps you have three off the shelf templates; Scrum, Agile and CMMI.  The templates can be customized, but it is clunky and requires a developer to do the work.  In my ten years working with Azure DevOps, I have not been able to do that task.  With Jira, they have the concept of workflows, and they are configurable.  I have witnessed project professionals’ fight about the configuration of workflows.  Azure DevOps allows you to configure boards with custom status columns referred to as “board columns,” but to update them, you have to view sprint backlogs or product backlogs to change them.  I consider this a serious limitation of the product and hope someone from Microsoft can show me how to do that inside a story or bug form.

The next issue is Jira has three types of backlog items; bugs, stories, and issues.  Azure DevOps only has two.  In Jira issues and stories behave in the same way.  I find this confusing, and I am observing my development community creating “tickets,” with no preference for them being stories or issues.  Off the shelf, Jira does not have tools to track git push/pull data.  You need to install a “hook.”  Build automation, and CI/CD features are also absent.  I find this absence to be a major stumbling point for Atlassian.  I should be able to track a story with code changes and build information seamlessly.

Finally, Jira appears to be very good at an individual project with one team, but it struggles at scale.  Issues, Bugs, and stories can fit into Epics, but there is no concept of a “feature,” or “area,” in Jira.  It makes it hard to “roll-up” stories into Epics for the business to easily see.  It also makes it hard to manage large backlogs because a backlog can only accommodate one team.  If you are attempting SAFe or LeSS you struggle to see dependencies between teams and how they time to larger product.  I am sure this is my lack of experience showing.

I do not consider Jira an anti-pattern or a necessary evil.  It is just a tool.  Like any tool, it can be used in a harmful manner and create serious damage.  As a coach, I need to be able to respond to change over following a plan.  Jira is certainly a change from how I am accustomed to working.  Fortunately, my agile coaches and mentors have given me a good working knowledge of how to manage a backlog.  If the stories and vision are clear, it does not matter what project management tool you use.  Jira is good enough, and I will accept it because working code in production is more important than the work item tracking tool which manages the process.

Until next time.

It is just like starting over

Listen, Listen, Listen.

The New Year is always busy.  The sloth of the holidays gives way to new resolutions and a means to wipe the slate clean.  I am no different.  I began a new role as a coach and scrum master at a new firm.  Today on the blog, I would like to talk about starting over and beginning a new agile practice.

A scrum master or agile coach lives an intenerate lifestyle moving from client to client.  More than many professionals they are starting over in new environments.  It means a coach needs to embrace responding to change over following a plan. It requires a certain humility and empathy for others.  Some organizations use Azure DevOps to manage the software development lifecycle, and others use tools like Jira.  Any good scrum master should be able to adapt to these different systems.  It might also be helpful to ditch a system entirely to learn the basics of agile. 

I find listening to others is helpful.  To drown out office noise, I often wore noise-canceling headphones and enjoyed a playlist of “New Wave” and “Post-Punk” music.  It made the day go faster, but it created a barrier between myself and others.  I did not understand how big a barrier until I decided to try something different and leave the headphones at home.  I began to hear QA people gossiping about bugs.  I learned about the favorite T.V shows of developers.  It was informative which people took calls via speaker phone and which ones were more discrete.  The office completed work in a particular way, and I gained insight into that process.  The insight is going to help me better coach others. 

Last year, I wrote a despairing article about my failure as a coach.  What came out of that experience was the realization before anyone can coach or guide others you need to empathize with them.  You cannot bully people into improvement.  People need to be shown the way and encourage to make better choices.  Experience and success will create a positive feedback loop of continuous improvement.  Leave the rough justice to managers who can discipline those who will not buy into the agile mindset. 

When starting over, shut-up and listen to others.  Cultivate empathic relations before learning.  Find out how your customers do things before proposing changes.  Finally, have some humility and respond to change.  Ever since Lee Iaccoa took over Chrysler in the early 1980s, professionals have worshiped the cult of leadership.  It is time to take a step back and realize that before you can lead: listen. 

Until next time.