Story sizing and 2 weeks sprint

I was part of a discussion where an argument between various members belonging to Engineering, QA, Scrum Masters, Product Managers and Release managers were debating about what should be the max size of a story. That forum wanted a “hard” limit of 5 days for a story – primarily because it will enable them to move to 2 weeks sprints from a current 1 month sprint cycles.

Here’s my take.

The reason we do Agile is to ensure that we get Predictability (in the form of feedback, reviews, validation etc). And predictability in  two important dimensions

  • Direction : Are we building the right thing?
  • Time :   Are we spending right time and on-schedule?

So, it’s not important if the MAX story size is 4 days or 5 days in a 2 weeks sprint. What’s more important is to understand whether a team is able to commit and deliver the body of work in a given sprint so that those Two important dimensions can be evaluated – Direction and Time.

As a guideline and best practice, we can suggest the individual teams that they should try to have smaller stories, leverage INVEST principle and all the other agile frameworks.

However, what should not forget that the objective of the process or any methodology is to help reduce chaos – and not bring rigidity. So, if a team has average story size of 6 but has high commitment to completion rate in a given sprint, then they should be free to stick to max story size of 6 days. If another team sees that keeping the story size to 4 days is better, then so be it. Infact, review or retro time could be leveraged to analyze a story which couldn’t be finished in a sprint to understand if there is a repeated co-relation between size and not getting done. May be a co-relation will appear that a story in a particular area if is more than x days, then the likely hood of it not getting completed in a sprint goes high. Then may be the Product owner should ensure that they breakdown the work in that particular area.

A blanket 5 day max rule across the board is not the right approach to agile.

Why now?

As a product manager, prioritizing work with a “Why” is not sufficient. I have seen many PMs or other cross functional team members do this mistake.

They will word-smith and justify why a feature, enhancement or even a defect needs to be addressed.

But a good PM instead leads a discussion with “Why now?”.

“Why” is a necessary condition but “Why now” makes it a sufficient condition.

[Idea] Feedback plugin for meetings

Meetings. It’s a big investment which every company makes. Do the companies know their ROI? Or how to measure?


How about a plugin

  • Records # of attendees in a meeting which tells the “cost” of the meeting
  • Gathers ratings and feedback (attendees can say if they were needed, if the agenda was clear etc)
  • Leaderboards it – and forces the meeting organizer to ensure that their meeting rating is above a threshold

Anyone working on it?

Problem Solvers vs Solution Providers

Problem Solvers:

  • They are focused on the problem and don’t care what role they are playing to solve the problem. They want the problem to go away.
  • They empathize with the user who is facing this problem and want to know more. They have questions. They are curious.
  • They feel comfortable to step out of their day to day responsibilities, if it helps to solve the problem

Solution Providers:

  • They stick to their solutions, even if those makes sense – because they feel comfortable with it
  • They do not step out of their comfort zone as it might make them vulnerable.
  • They try to create boundaries around them so that anything outside their role is not their concern.  Never put themselves in place of users or peers

Become a Problem solver and not a Solution provider.

[Idea] Code and Infra Bot

Although for living I do Product management wudoo magic, but end up writing a lot of code.

As a developer and user of these cloud platforms, here’s my wishlist. Hope someone solves it. (or I might have to rollup my sleeve and do it 🙂 )

TL;DR: Even if infra availability and management has become easy, it’s still a lot of learning and work. It ends up taking my focus away from code.

  • None of the public cloud providers give a Dev, Test, Live environments. While everyone should know that a developer needs “atleast” one non-prod environment.
    • Why don’t you ask: “Hey, does this app require an additional non-live environment”? (look at, Stripe, – to name a new – they totally get the value of giving additional non-prod environment(s))
  • Why ask us to write so many YAML files? Programming languages have been abstracting the underlying machine level instructions, stacks like containers/ k8s have been abstracting the nitty – gritties of packaging and operations etc, so why not abstract how these abstractions work?
    • Just ask few questions:
      • Which cloud?
      • Looks like you are deploying Rails – do you care if your app goes to appengine or k8s?
        • If yes, ask which one – and generate appropriate app.yaml or docker files. If no, just do that stuff in background.
      • Do you need HA for your db? (another way to ask could be : Is this for Prod because I can give you HA for that)
        • Again, update appropriate config files in the code or wherever needed
      • Looks like you are deploying a container – Is this a background service or does it serve a web request?
        • Based on the response: Create appropriate deployment/ service yaml files
        • Yeah, if it’s a web container, you can ask more questions – ports etc.
    • If the YAML/ config needs to be upgraded in future, then this service should help upgrade.

Hope someone builds infrastructure management from the viewpoint of a developer.

Look around – we are building chatbots for sales, support, e-commerce and so many other domains – why can’t there be a bot for a developer or ops person?

Why and Why?

Two types of people and how they react to WHY?

First Type:

  • If you are a seeker:

You are curious to learn. You want to know the context so that it helps you in future. You do not accept things because someone said so.

  • If you are a giver:

You take a moment to understand the problem. You are not annoyed with so many questions coming at you and you have to patiently reply to them. You feel comfortable saying “I don’t know, but I can help to find out”. You believe in sharing as the more you share the more people learn and the organization grows.

Second Type:

  • If you are a seeker:

You like to ask a question because you have an opportunity to ask a question. You think you are skeptic but you are a cynic – almost all the time. Learning is not your objective. You are not keen on the problem but want to check if the giver is ready to handle your question or not.

  • If you are a giver:

You think most of the questions asked to you are naive or stupid. You expect people to know stuff and you get annoyed when you hear questions.

The power of surprise

Ask — Will it surprise my audience? — If the answer is yes, then go ahead! It’s all about “Surprise Quotient” (SQ)

We all know how Dick Fosbury at Mexico 1968 games surprised the spectators by changing the paradigm of high jump and coined the new term — “Fosbury Flop”.

The element of surprise is what wows the audience, or makes an idea look innovative or disruptive (the two overly used words in the past few years).

Steve Job’s famous “One last thing …” is a perfect example of making the audience long for that surprise element. We all knew that he has a special secret for us. Secrecy and Apple go along very well, and I think it’s the secrecy — the surprise element which makes Apple fans die for the products.

Surprise has played a big role in meddling with human emotions. It also plays an important role in marketing too.

Beyonce surprised her fans by announcing about her new album on Instagram — it’s this non traditional way of launching an album — which got additional media and PR attention. And made her look even more cool!

As far as startups are concerned, they can use all the buzzwords like disruptive, innovation, hustler but it won’t make them successful until their product (or services) surprise their audience. The audience should fall “head over heels” for this new business. Be it disruption of Microsoft, Apple, Uber, Square (or the current favorite Bitcoin) — they attracted the users because they made us say — “Wow, I didn’t know this was possible in my lifetime!”

So, when you show your product to the users, see if their eyes glow. If they get excited! Try to gauge their “Surprise Quotient” (SQ).

(originally published on Medium)