Getting Better At User Stories

I’ve been running product teams for 3 years now and been part of product teams for 7, I’ve seen the failures and successes from both perspectives and there are 2 approaches to a given project that will definitely fail.

Approach 1 is for the delivery lead to go into a room alone and flesh out the requirements and subsequent user stories alone, finally emerging and presenting their vision to the rest of the team. This approach almost always results in questions from the team members and missing requirements identified.

Approach 2 is to involve the entire team and maybe even the stakeholders in a workshop to outline the requirements and subsequent user stories. The stakeholders will invariably end up having arguments amongst themselves about what they want and what is most important. The product team will outline the requirements and user stories to capture almost everything, but there will always be something missed that comes up later.

Either approach ends up with lost time but there is a strategy that will enable teams to leverage short meetings to focus their efforts. By conducting a mini-workshop focused on a single objective or minimum marketable feature, the right participants can be identified and invited. This also breaks down the greater vision to a single objective that can allow the team to see the wood for the trees, so to speak.

Story mapping is a good visual process that allows you to identify the sequence of actions in a user journey and the alternative paths a user might take. Each action is written in such a way that the word ‘then’ can be inserted between each pair…

Sign in -> Then -> Search Products -> Then -> Add Product To Basket -> Then -> Purchase Product

Post-it notes and a wall are ideal for this approach because you can easily move actions along the sequence axis as well as up or down the alternatives axis. The alternatives axis allows the team to agree what actions are most important and which are less important.

This approach of small workshops spread across a project leads to a better delivery of the product over time, compared with outlining everything upfront and finding everyones memory fails when they try to recall something 6 weeks later. Our modern brains are not designed to hold onto information for long periods, that is why computers are for, by having computers to store information we free up brain power to be creative and in the moment.

Blade Runner Is 3D Printers On Mars

I have a smart phone, it is incredible what I can do with it. I could run my entire work day from it if I wanted to. I can check email, instant message on slack, and manage projects from that little screen. It wouldn’t be easy but it is possible and reliable with a good wifi connection or 3/4G. One thing bothers me though, I still can’t guarantee that I will have a crystal clear conversation with somebody. The fundamental feature of a phone is to have a vocal conversation with somebody, so why is it that we as a community skipped that problem of the unreliable cellular network?  I’ve lost count of the number of times I have had a phone call cut short or broken up because I cannot hear the other person clearly or the connection has dropped due to signal issues – good thing I can reliably play candy crush though.

We have a printer in our office, not true actually, we have 3 printers for about 20 people max. None of these printers are reliable, each has their own quirks and some people have their favourite because they have worked out how to use it, I know I have. We are apologists for crappy technology, we work around their flaws to meet our goals and forget about it. As a species we have skipped the office printer and gone straight to the 3D printer, even though 3D printers wont allow me to print that document I need. It’s like a kid trying to concentrate and then catching sight of the playstation and forgetting all about their homework.

Airplanes crash, a lot. A lot more than they should do I feel. Frankly I think it is crazy that we (myself included) are willing to climb into tubes with wings and thrust into the sky. Remember this, a passenger plane is just a train carriage with wings. Everything we travel in is basically a tube with appendages to suit the external environment. So airplanes crash, trains crash, cars crash, but apparently the most important thing to do right now is fly out of our atmosphere and travel 54 million kilometers to another planet. Yet we cannot rely on our current forms of world travel.

Have you ever watched Blade Runner and wondered how this version of our future selves has managed to create human like androids that are so convincing as humans that even the android itself cannot realise it is not human, and yet for some reason nobody has fixed those leaking street pipes. Los Angeles is more polluted than ever, over populated, and everywhere you look there are derelict buildings. This is the world we are moving into by skipping the fundamental things nobody has solved yet because they got distracted by the shiny things. We will end up in a world where the poverty gap is even greater, and the technology gap will be just as great.

Blade Runner underlying them isn’t some futuristic robot chick flick, it’s the resulting disparity of technology and its impact on the human race as a culture.

Don’t Pay For SEO

I’ve watched people sell their SEO services for years now, I have heard all about the magic tricks people are saying they can perform to get you to the top of Google (other search engines are available) and frankly they are over-selling it.

I can get you to the top of Google for [insert trade] in your [insert small village] but that is something you can do with just 2 pieces of knowledge. You can pay hundreds or even thousands for someone to do something that will be described in such a way that it is beyond you to understand but frankly they would be BSing you so don’t believe a word.

Google is a HUGE company and they employ thousands of highly paid engineers that know MUCH more about the internet than any freelancer or agency. Anyone who tells you they can do better than another company is a liar and even more than that, you can do better on your own.

Rule number 1 is Be Relevant.

This can be text, images, and videos. Anything that Google will deem relevant to a given search term will land in search results, yes they are highly unlikely to land on page 1 but this is just the start. No tricks required, just write content around a subject and you’ll be considered relevant, the more content you produce on a subject the more relevant you will be considered. There are no tricks here, Google provides you with the most relevant result when you search for something and that is the way you want it. If Google served you preferred but less relevant content you would stop using Google. Your target customers will be served relevant content and if you provide relevant content you will rank highly, it really is that simple.

Rule number 2 is Be Respected.

This one is a little more difficult but no less accessible. Respect comes from links, you want to be linked to by other highly relevant and respected websites. Most companies will tell you how they will backlink from highly ranked websites but frankly they are just back linking from websites designed just to back link to their customers websites so they can point to a number and show you how many websites you are linked to – it’s worthless. Remember all those highly paid Google engineers, they are writing complex algorithms that make these tricks worthless and in some cases dangerous for you as a website owner.

What you need to do is contact website owners of related material and propose a link swap, where you link to their website and they link back to you. Get in touch with journalists that will be willing to write an article on your behalf an back link to your website in the article. You get the picture, it is not beyond your ability as a website owner to grow your respectability so just put the effort in to do the work and save yourself the money.

SEO is easy money, it is considered beyond most people to learn effectively but that is a lie. I could get you from zero to as good as anyone else in less than a day. I guarantee it.

Velocity Is Not A Number

2 figure velocities aren’t bad, but I’m just used to working with 3 figure velocity teams

I was working with Not On The High Street and heard this from a contractor Scrum Master, he played more of a supervisor role but let’s be honest – you can get paid more calling yourself a Scrum Master. I was playing the role of Scrum Master for a subset of a team amounting to about 30 people and rightly playing the role of protecting the team and its performance from such misinformed statements.

My first response was, “well we can stick a zero on the end of each estimate and instead of being a 34 point team, we can be a 340 point team. It wont change what gets done but it will keep the big wigs happy knowing it is a bigger number – despite not understanding what a velocity of 340 actually means.”, it was a somewhat sharp response but the situation warranted the tone.

The key underlying point to remember is that velocity not a number. This goes beyond the argument that some teams estimate tasks by t-shirt sizes and so could not be a number, but imagine the conversation above playing out with comments such as, “I’m used to working with XL velocity teams”. Estimates are relative and the amount means nothing in terms of output and everything to do with projection.

The correct use of velocity is to help the person responsible for delivery identify if the work being done is on track or not. If the velocity suggests that the work remaining is not going to be delivered on time, it is the responsibility of the Delivery Lead to have the hard conversations with stakeholders and find a resolution. I’m not afraid to tell someone I expect a project to go over schedule because I know there is still time to do something about it, I am however afraid to give someone the same bad news when there is no time left to respond to the situation. Remember: people can deal with bad news now, but they hate bad news too late.

Pop Quiz Hot Shot

A good test to ensure a person understands that velocity is not a value to be held against the team is to pose the following scenario:

There are 2 teams; Team A and Team B.
You require each team to estimate and complete 10 tasks.
Team A estimates each of the 10 tasks as 3 points
Team B estimates each of the 10 tasks as 5 points
Both teams complete the 10 tasks in the same period of time.
Which team was more productive?

I’ve heard the answer, “the team with 50 points” more than once would you believe. The real answer is of course that both teams are equally productive. I appreciate this is a trivial and convenient example but it is useful for illustrating the point. If someone asks you to increase your teams velocity be sure to ask for more resource or just bump up each estimate, both approaches will see an increase in velocity but only one will actually increase productivity.

No F*cks Given To Velocity Number

I honestly don’t give a f*ck about the number when it comes to velocity, I don’t give a f*ck about the number when estimating, what I give a f*ck about is what is most important and that is that the sizings are relative to other sizings and reviewed regularly. I often start by letting estimates be assigned and don’t question anything until we have a control batch, at which point I ask questions like “is this story still X points considering this other story is Y?”, and “are these stories both X points, or is one more or less than the other?”. Again, estimates are relative and the key to accurate estimates is to compare and adjust appropriately as more information becomes available.

Once upon a time I was introduced to the concept of estimations and velocity, along with other “sexy” sounding terms – I mean come on, Velocity, it sounds so fast and efficient – give me a break. My point is when I first encountered these topics I took them at face value and believed everything I was taught, for better or worse, until I eventually took a step back to consider what the point of all this was. All these methodologies are great and add value to cohesive teams but if I didn’t dig deep and work to understand why we were doing these exercises I’d just be continuing on as an agreeable employee, keeping my head down and pretending I understand as much as the next team member – which could only last so long.

And one last thing…

3 points is 1 day, so I would say this is probably a 3

Seriously, if you are going to take this approach you might as well ditch story points and estimate based on time. Then your superiors will ask why the commitment didn’t get completed in the sprint period and you can spend your time explaining why you cannot accurately predict the future.

 

Cult Of Agile

I have been working in software for 8 years and I have held a number of positions including Frontend Developer, Backend Developer, Scrum Master, Product Owner, and more recently I have adopted the role of Delivery Lead. It isn’t a commonly seen role in software development, not a “sexy” title worth its weight in gold according to the Agile Alliance, but it is a more accurate depiction of what I do, and it is effective.

I started as many do on the software development ladder as a junior developer. I watched and read and did, and repeated that process gradually improving. I observed as Agile and in particular Scrum became the key to solving all our problems as a provider of software development services. I will focus on Scrum in this article

Scrum brought with it these strange roles such as Scrum Master and Product Owner. I have never seen a true Product Owner, willing to make decisions or define requirements or decide priority, or even be available to the team when needed. I always understood that the Scrum team was a combined unit that worked together to ensure the “ball moved up the pitch and across the goal line”, and any kink or omission in the chain would lead to the teams downfall. I’ve seen projects succeed and fail regardless of the competence (or existence) of a product owner, and in most cases the Product Owner is pushed into the role rather than chooses it of their own free will.

Perhaps it is the term ‘owner’ that intimidates people, after all whatever is delivered becomes the responsibility of the Product Owner. Frankly the role is not hard, you just make decisions based on the information you have at the given time, and each sprint you assess and adapt you decisions where needed to better fit the vision based on the information you have at the given time. Maybe the problem isn’t in the person doing the role and instead is the misunderstood opinion of those higher up that shape the role into something to be feared rather than embrace.

That brings me to the Scrum Master, apparently the most valuable role in the Scrum team at least according to the number of articles and videos about the importance and value of the role. One of the key responsibilities of a Scrum Master is to “Protect the team”, apparently this undeniably successful concept that has not, I repeat NOT, been stolen and rebranded in an effort to make as much money from teaching people how to deliver products in the new modern landscape of software development needs protecting. Protect it from who?

Protect your team from those that don’t truly understand Agile, those that have operated in business for years, decades and in some cases centuries, somehow growing and expanding before, during, and after the birth of Agile and the formative years. Francis Bacon, Shewhart, Deming, Takeuchi, and Nonaka must be looking down and wondering how this concept has grown through their respective careers, and turned into a cult. Sweeping through businesses the world, guaranteeing results so long as you follow the rules to the letter, and yet somehow there needs to be a protector in every team.

Time To Adapt The Process

At the root of succeeding in Agile is the ability to adapt, at the end of a sprint you stand back and look at what you have produced and how you have produced it, and you make changes to adapt. Why must the process that encourages adaptability follow fixed rules masquerading as loose guidelines?

Free yourself of the Product Owner and replace that role with the Decider role. This person is responsible for making decisions in a timely fashion based on the information they have at the given time. Hindsight is a beautiful thing, you know the outcome and you can make the judgements understanding the impacts after they have happened. The Decider is immune from persecution should their past decision turn out to be off in hindsight. Team members are encouraged to challenge a decision and ask questions, test the defences and work as a team to ensure the decision is a robust decision.

Scrum Master – protect nothing. Let all challenges come and test the tolerance of the process, remove yourself from the echo chamber and hear reasoned arguments from those that may hold the key to the next evolution in this improvable concept.

When you find yourself on the side of majority, it is time to pause and reflect.

I have since rebranded myself as a Delivery Lead (hey, if the Agile Alliance can brand themselves, why can’t I?). My job is to get the product delivered on time, in budget and within scope. This is a fundamental of business, ensure you bring in more money than goes out. People pay happily when you deliver.

I know the “budget is tight”, and there is “no time”, and the “scope is creeping”. The budget has been decided, the timeframe has been plucked out of thin air, and the client expectations need to be managed if you want to protect the scope of the statement of work. Be willing to have the hard conversations and your team, your boss, and eventually your client will thank you. Pushing back on scope creep is not about fighting against your client, it is about guiding your client through the period to ensure what was promised gets delivered.