5 Things Learned From Steve Jobs

Last week, I (virtually) attended the Lean Startup Conference and heard Guy Kawasaki – former Chief Evangelist at Apple – speak about 10 things he learned from Steve Jobs. Below are the 5 that caught my interest, along with some of my thoughts…

1. Customers can’t tell you what they need (you need to help them figure it out)

I think it is important to keep in mind that building the right feature takes collaboration and communication. This is similar to how a Product Owner presents a user story to the dev team and then there is a discussion to clarify points, add acceptance criteria or discuss why another approach could be a better idea.

2. Changing your mind is a sign of intelligence

This is very much in line with Agile thinking, which is why we work iteratively and incrementally and why continuous improvement through inspecting and adapting is so important.

3. Engineers are artists – treat them like artists

Just like an artist, engineers need space to be creative and innovative (no micro-managing). They also need time to work on their craft, for example, time to refactor so they are not introducing technical debt.

4. Innovators ignore naysayers

There are many reasons why people will say something can not be done. Perhaps they don’t understand the vision, maybe a particular idea threatens them or they don’t like thinking outside the box.

5. Some things need to be believed to be seen

Guy explained this as the idea of sometimes people won’t take the time to see something until they’ve been convinced of the idea. So, really understanding the benefits of a feature, being persuasive and convincing people of the idea many times is the first step.

Please let me know what you think.

User Stories – Size Does Matter

Agile User Stories


No matter what team I’m a part of or what meeting I’m in, the topic of smaller user stories is regularly broached. The reason? Because it is really important. At the same time, smallerizing stories can be quite challenging. However, as challenging as it can be, it is well worth the effort. Here are some reasons why I think it is beneficial to create small user stories.

Small user stories are more clear

When stories are large, there is more information contained in the description and more acceptance criteria to be considered. Sometimes this can be too much to wrap your head around. For example, when there are about three stories worth of information contained in one story, it’s harder to understand the scope and chances are that there will be multiple dependencies introduced. When stories are small, they are easier to understand which allows you to focus on what is right in front of you.

Small user stories are easier to estimate

Going hand in hand with smaller stories being easier to understand is that smaller stories are easier to estimate accurately. Would it be easier to guess the weight of an elephant or a cat? I recently conducted a small survey asking people to estimate those weights and each time the estimate for the cat is much, much closer. Try it yourself. You can also see this in the Fibonacci sequence that is commonly used in Agile estimating. As the numbers get larger, there is more room between them which indicates more ambiguity and less precision. 1, 2, 3, 5, 8, 13… these numbers are all pretty close to one another… 21, 34, 55, 89, 144… not so much.

Small user stories introduce less risk into the sprint

Have you been part of a team that had a 21 point story carry over to the next sprint? It was almost done, but not quite. At the sprint review, the stakeholders are now a bit disappointed because they were hoping to see that new checkout flow they’ve been dreaming about for the past two weeks. Imagine if the team had broken the story out into 4 or 5 smaller stories, for example. The stakeholders would have loved to see how the user can add an item to their cart and then add their credit card, even if they didn’t get to see the confirmation screen and email. But now they are sad and wonder why they attended the review in the first place.

Small user stories increase the workflow

Maintaining a steady workflow is important to help the team get in a rythym and avoid bottlenecks. Perhaps you’ve witnessed a large user story stuck in progress for over a week while Johnny QA is twiddling his thumbs and tapping his foot just waiting for the chance to find those bugs. Smaller stories lead to a better workflow and less bottlenecks, which lead to better team productivity.

Small user stories help shorten the feedback loop

When user stories are smaller, they are completed faster, therefore providing the Product Owner and other stakeholders the opportunity to provide feedback more often. When the team receives feedback more often, they can be ensured that they are working on the right stories, which in turn, ensures that the correct product is being built.

Can user stories be too small?

Yes, definitely. I remember one team in particular that I was on where the size of stories was discussed in the sprint retrospective. The team all agreed that the stories needed to be smaller. The next retrospective, we were discussing that the stories were too small. So, even though it is beneficial to have small stories, beware of making them too small. For example, if you are changing the size and color of 5 headers on a page, it’s probably overkill to have 5 separate stories for that. The overhead of creating and moving the stickies or updating the tool is probably more work than actually updating the headers.

To sum it up, small user stories provide clear benefits and add more value than larger user stories. However, breaking stories down is not as easy as it sounds and the team needs to work together to find the right size. It takes team collaboration and it takes practice. But it’s worth it, so give it a shot with your next batch of user stories.