Better Sprint Planning

Abraham Lincoln on Planning

A Sprint Planning meeting produces the following artefacts

  • A Sprint Goal which is a short description about what the Product Owner (PO) and the team have agreed to achieve in the Sprint.
  • A Sprint Backlog which is a set of prioritised and estimated user stories and their respective tasks that the team has committed to in order to achieve the Sprint Goal

The team needs to have full clarity on both the above artefacts in order to deliver working (shippable) software in accordance with their Definition of Done at the end of the Sprint. So that the Sprint is worth the while of the team and worth the money the client is spending for that Sprint, each member of the team needs to understand the Sprint’s stories and the tasks included therein well. This also includes the UI designs or wireframes for each story included in that Sprint. While the stories describe the functionality, the UI designs / wireframes describe the form.

Let’s look at the Steps of a Sprint Planning meeting:

1. Review the Product Backlog

The PO starts describing the stories from the top of the backlog along with their respective UI designs/wireframes. The team usually asks questions regarding the stories being discussed which the PO answers. Once the team has complete clarity on what needs to be done to complete the user story, the team creates a list of tasks (usually technical in nature) for each user story. The QA person (if you have a specific person for this role) also mentions some test cases he would use for black box testing. However, he is free to include them during the course of the Sprint too. What is relevant and what is not can always be discussed among the team and the PO.

2. Estimate the Sprint Backlog

When the team feels they have discussed enough stories from the top of the backlog, they start estimating the same. The preferred way is to estimate stories in Story Points and use Planning Poker so that everyone is on the same page and the estimate has acceptance within the team.

3. Commit

Based on the team’s current velocity and the time available within the Sprint, the team makes a commitment on what stories it would complete at the end of the Sprint as per the definition of done without skimping on quality.

Now let’s try and understand a Sprint Backlog in depth so that we know the expected output from a Sprint Planning meeting. A Sprint Backlog has the following attributes:

  • It is a subset of the Product Backlog
    • Whatever the PO/Client feels needs to be a part of the product forms the Product Backlog. The Sprint Backlog is a subset of it i.e., it cannot include anything that is not a part of the Product Backlog. Sometimes, there is a need for some technical housekeeping for which the team can request the PO to include (and prioritise) in the Product Backlog. They can be included in Sprint Backlog too provided they are a part of the Product Backlog first.
  • A Sprint Backlog requires a commitment from the team on what would be delivered at the end of the Sprint. This team commitment needs to:
    • be clearly understood and agreed upon by every single member of the team and the PO too
    • be achievable without sacrificing quality
    • be achievable without sacrificing sustainable pace (it is okay to stretch once in a while but not every time)

So now we know what is expected out of Sprint Planning and what are the steps thereof. Let’s now consider some salient points that contribute towards a fruitful Sprint Planning

  • Fixed Start and End Days

A Sprint needs to start and end on the same days (I am considering Sprints that are 1-week, 2-week, n-week long). So if your Sprint cycle is Monday to Friday, it should never change. This helps get into a periodic rhythm that is felt by the entire team. All Sprints are equal sized and this never changes. A Sprint is all inclusive. Apart from the project development, it also includes Sprint Planning at the start and Sprint Review and Retrospective at the end.

  • Include Everyone

A Sprint Planning includes everyone on the project – the PO (and the client too if possible), the Team (including the developers, QA persons, UI design persons), and ScrumMaster

  • Sync Sprint Plan With the Client

If the client is not present in the Sprint Planning meeting and the meeting is chaired by the PO, it is imperative that the PO syncs up with client to apprise him of what all has been committed to in the Sprint Planning. The client might have a rough idea initially as he had prioritised the backlog but this sync up would make sure he knows for sure what to expect at the end of the Sprint.

  • Include Spikes

As it happens on most complex projects, there are functionalities / technologies which no one in the team might have experience with. Such functionalities require researching and building a proof of concept perhaps. For such unknowns, it is good to include a small time box within the Sprint (one or two days for example) for researching and checking the viability. This is done a Sprint in advance. Such a spike reduces the uncertainty when the team comes across implementing the functionality actually and helps them estimate the story appropriately.

  • Abnormal Termination

There may be a rare case that the Sprint Goal that the team is chasing becomes irrelevant in the middle of the Sprint. In such a case, the Sprint can be terminated in the middle and then a new Sprint is planned. However such terminations should be exceptions, not rules. Whenever you have changes being requested to the current Sprint, they should be prioritised to be taken up in the next Sprint. Only in the extreme case should one consider terminating a Sprint in progress.

Now that we have a good hang of what a Sprint Planning (and Sprint) includes, let’s look at Five Commandments for Sprint Planning

1. Thou Shall Stay a Sprint Ahead of the Team

The PO should stay a Sprint ahead of the team grooming the backlog, making sure that the epics are broken down into user stories, arranging the UI designs / wireframes for the stories in the upcoming Sprint, and identifying stories that might need Spikes to be included in the current Sprint.

2. Thou Shalt Not Extend the Sprint

It’s possible that the team is left with an incomplete story at the end of the Sprint. They might consider extending the Sprint by a day or two to complete the pending work and fulfil the commitment they made at the start of the Sprint. This should never be done. Never, ever. Sprint delivery includes completed stories and incomplete / pending work gets put back on the backlog for prioritisation. The Sprint is never extended. This ties in with the point above of having Fixed Start and End Days.

3. Thou Shalt Not Include Extra Time

Never factor in extra time (apart from working hours) in a Sprint. PO / team might be tempted to consider after hours or weekends to meet an aggressive target or complete stories committed in a Sprint. This can be considered only in the rarest of rare cases and should never be encouraged. This ties in to the principle of sustainable pace within a Sprint. While it can be permitted for a couple of days in the project, any longer than that and the team would be setting itself up for failure and lower productivity.

4. Thou Shalt Not Add More Work

Adding more work in the middle of a Sprint is something that Agile is strongly against. The team commits to a set of stories according to their Definition of Done that makes their Sprint Backlog. That backlog should not be messed with. The PO should not try to add / change stuff that is already a part of the Sprint Backlog. Only if the team agrees can the PO swap some item in the backlog with another equally sized item provided it doesn’t derail the Sprint. Any changes can be considered in the next Sprint. But no work should be added to Sprint. However, if the team finishes early, they are allowed to pull in more stuff from the Product Backlog into their Sprint Backlog but not otherwise. Adding more work to a Sprint in target would amount to hitting a moving target and is a sure shot recipe for disaster.

5. Thou Shall Deliver After Each Sprint

The team should deliver working software as per the Sprint Backlog and the Definition of Done after each sprint. No exceptions. This should be delivered to the PO / client for User Acceptance Testing and any changes / feedback should be put back on the Product Backlog for prioritisation.

There is the concept of a Sprint 0 that is a double edged sword. It can have its benefits if handled properly else it can cause you to slide back into Waterfall. The purpose of a Sprint 0 is to:

  • bring the team together and give them a high level overview of the project
  • set up tools (code repository, project management, story board tool, etc.) for the project
  • check tech feasibility of risky components of the project
  • get UI design and wireframes done for the first Sprint
  • break down epics into user stories for Sprint 1
  • arrange resources like App Store developer account, servers for development / testing, emails for support, etc.

Sprint 0 should not be mistaken for a mini Waterfall wherein all stories are attempted to be defined in detail upfront, UI design completed upfront, etc. All these tasks happen Sprint by Sprint (being one Sprint ahead of the team). The focus should be on emergent design (both architecture design and UI design) during the course of the project and not everything upfront.

Though the above seems like a lot (and probably it is) but once you get into a rhythm of doing it, it becomes natural. It is similar to learning to drive a car wherein you have to do a lot at the same time – control the steering wheel, keep the foot on the accelerator, change gears occasionally while pressing the clutch, look in front, look in the rear view mirror, look in the side view mirror, be ready to hit the brakes! After some time it gets so smooth that you can do all the above (and more *wink*) with ease. Same is true with Sprint Planning. If you learn to do it well, the project execution would be very smooth.

Scrum Roles

Scrum Roles

Scrum is by far the most popular framework under the umbrella of Agile software development frameworks. It allows for greater visibility to product sponsors while allowing the development teams to build incrementally and iteratively.

For Scrum to be successful, it needs a certain degree of discipline. That discipline requires that team members have specific roles and responsibilities even when they are encouraged to be cross-functional and support other team members from time to time.

Scrum defines 3 roles – Product Owner (PO), ScrumMaster (SM), and Team.

The PO is what it sounds like. This person owns the product from a functional perspective. He writes the user stories and puts them into the backlog. Before each Sprint, he refines the backlog to ensure that the stories are the right size in terms of effort and complexity for the development team to work on. He ensures that the backlog is prioritised at all times (highest priority stories at the top of the backlog and lowest at the bottom). He frequently grooms the backlog akin to grooming a garden – removes stories which would not be required in the future, adding new stories to the backlog, and refining the ones already on it. Whenever, the team seeks any clarification on the functionality or the priority of the stories, he is their go-to guy.

The way a PO owns the product, the SM owns the process. While the PO ensures that the team build the right product, the SM ensures that the team builds the product right. He works with the PO in ensuring that the all meetings required to make the product and process smoother (Sprint Planning, Daily Scrum, Sprint Review, and Retrospective) are held regularly and in the right spirit. He makes sure that the development team is not pressurised into taking on more work than they can handle. While the PO is busy gathering and giving feedback about the product, the SM does so for the process.

The third and equally important role is that of the Team. The Team comprises of anyone and everyone working on the product technically. It includes developers, UI designers, and testers. They are responsible for building the product as per the acceptance criteria specified by the PO while following the process set by the SM. They own the quality of the product. They have a right to take on only as much work as they can finish in a Sprint without compromising on quality. They are also welcome to request the PO to include stories that would benefit the product quality and maintainability.

Together, the three roles in a scrum form the 3 sides of the project pyramid and offer great stability to the development process. Together, they ensure that the right product is being built right. If any role takes on a weak or a dominating stance in the team, the project suffers. Thus, it is imperative for each of these three engines to fire consistently in order to move the ship forward.

The team is also referred to as “Pigs” (because they are committed to the project) while the PO and SM are referred as “Chickens” (because they are just involved). The following image lends context to this nomenclature.

Chicken and Pig

Agility @ Appster

Appster Logo

As on today, I am working with Appster as an Agile Coach and Senior Project Manager. Here’s what I have to say about the process we are following at Appster.

In order to build a great product, you need to have a greater process. A process that is simple yet flexible. A process that lays emphasis on quality yet allows change as you go. Agile emerged as an answer to this need. It is a software development framework suited to humans – people cannot predict the future accurately and would like changes to be accommodated in their plans; humans can focus only one or two items at the same time and not the whole gamut. A quick look at the Agile Manifesto assures one to the flexibility inherent in an Agile development environment.

At Appster, we are trying to imbibe the spirit of Agile in its purest form. It all begins with the signing of an Agile contract with the client. The client is not bound into an iron-clad contract (reminiscent of the Waterfall model of software development) but allowed to make changes to it as long as the primary constraint (scope / time / cost) is unaffected.

The client’s requirements are captured not in an exhaustive document covering reams of paper but into high level User Stories (called as Epics). Epics allow the client to express the desired functionality easily while leaving enough room for change / discussions.

Then the dev team breaks down these epics into smaller User Stories that are the right size for development and planning. The entire development is broken down into two-week long iterations called Sprints. At the beginning of each Sprint, the highest priority User Stories are discussed in detail and planned to be completed during that Sprint. The design, development, and testing for each User Story is encompassed within the Sprint only. This is in sharp contrast to Waterfall development wherein each of these was a phase in itself. At the end of the Sprint, the client is presented with working software in the form of a build. While the client does User Acceptance Testing of the build, the team retrospects about how it performed in the last Sprint and what improvements it can include in future Sprints.

During the development, the client is welcome to change any requirement for which work hasn’t started already. The client is free to make changes inline with the scope / timeline agreed upon. The team approaches client interaction with a mindset of collaboration rather than contract negotiation. Even changes that are beyond the contract are acceptable if both the parties are willing.

The above process allows the dev team to deliver working software frequently and in increments. It allows the client to be deeply involved with the development process and see his app take shape and grow like a tree. It also allows (and even welcomes) changes to the application that make it relevant to the current situation of the market and competition.

How to Raise a Lean Startup – V

Lean Startup

<< Part IV

The previous part talked about growth of a startup. But an entrepreneur needs to ensure that the growth happens in an orderly fashion, quality doesn’t get compromised in the rush for mad growth. Any shortcuts committed now would speed up the process only in the short term and would slow down future changes. This is a fact known to every good software developer. If you skimp on quality now, which amounts to incurring technical debt, you would have a tough time making changes to the code later. The only solution would be to slow down first and pay off the debt by improving the quality. Once quality is maintained, the process automatically picks up pace and cruises along smoothly.

There is a root cause analysis technique called Five Whys. It allows one to get to the bottom of an issue by repetitively asking “why?” to each response. Ries suggests using the same to identify issues with the process and making a commitment for solution at each level of why in tune with the problem. Also, the following rules help build a smooth, error-free process:

  1. Be tolerant of all the mistakes the first time.
  2. Never allow the same mistake to be made twice.

Ries says that startup teams need to have a certain structure in order to have a good chance at success. They need to have the following structural attributes:

  1. Scarce but secure resources: there should be just enough resources that the startup needs. Too much of it would cause wastage and too less would stifle growth. And the resources should not be poachable.
  2. Independent authority to develop their business: because a startup is required to carry out experiments and tune its engine, it needs full autonomy to develop and market its products in order to achieve success.
  3. Personal stake in the outcome: unless the team feels personal about the product it is building and unless its own success is tied to that of the product, there’s only a slim chance of success.

Reiterating a point that was mentioned earlier in this series, a startup should focus on doing the right thing first and then doing things right. In software development, the practice of Test Driven Development (TDD) ensures that only as much code gets written as needed. Nothing more, nothing less. This blends well with one of the main principles of Lean which aims at reducing waste.

This concludes the series of blog posts on Lean Startup.

Disclosure: This series is primarily based on Eric Ries’s book The Lean Startup. I have added to it my own experience with Lean and Agile as software development methodologies.

How to Raise a Lean Startup – IV

Lean Startup

<< Part III

The first three parts spoke about starting up your startup. This part talks about how to sustain the momentum, or better still, increase it.

Lean thinking advocates small batches of production, if possible, batches of one. This is based on the principle of keeping the feedback loop short. A short loop allows production / quality problems to surface sooner. This is why Sprints in Scrum based software development are kept as small as possible. This is why user stories in Scrum are also kept small in size. Small sizes allow incremental and iterative development while large sizes tend to list towards all-at-once delivery.

Continuous Integration, a key practice of any Agile software development organisation is also based on the above theory. Toyota’s production systems encouraged a culture wherein any person part of the production system could stop the production instantly on spotting a quality issue. Both Continuous Integration and Toyota’ production system recommend the following steps:

  1. The change that introduced the defect to be removed immediately
  2. Everyone on the production team to be notified of the defect
  3. The production to be stopped immediately to prevent introduction of further changes
  4. The root cause to be identified and fixed immediately

Having a smooth production system isn’t enough. It also needs to grow, and sustainably so. Ries defines sustainable growth as one where new customers come from the actions of past customers. This can happen in one or more of the following ways:

  1. Word of mouth: existing customers talk to other people who buy the product on hearing positive opinion.
  2. As a side effect of product usage: other people feel compelled to buy the product on seeing existing customers use the product or engaging with existing customers while the former are using the product.
  3. Through funded advertising: advertising is paid out of the revenue that existing customers generated and this creates a positive feedback flow in terms of revenue where the cost of advertising is less than the revenue generated by a new customer.
  4. Through repeat purchase or use: some products are inherently designed to encourage repeat purchase, for example, subscription, or consumables.

Now startups can leverage the above to form a growth strategy which Ries terms as engine of growth. Startups can employ one (or more) of the following engines of growth:

  1. The Sticky Engine of Growth: this encourages long term retention of customers (makes them stick to the product). The net growth rate is calculated as the natural growth rate minus churn rate.
  2. The Viral Engine of a Growth: this depends on person to person spread of influence (deliberately or involuntarily) like the spread of a virus. Growth is measured by a viral coefficient: the number of new customers each new customer brings.
  3. The Paid Engine of Growth: this encourages maximising the returns on each new customer by either reducing the cost of acquisition or increasing the revenue.

Continue to Part V >>

How to Raise a Lean Startup – III

Lean Startup

<< Part II

I practice Scrum / XP in the software projects I manage. As part of the same, the team iterates over sprints during the development of the project. The sprints are kept as short as possible (usually a week long) so that feedback loop is short. At the end of each sprint, the team gets feedback on whether they built the right product or not. Likewise, for a ship cruising on the ocean, frequent checks of the current route vis-a-vis the planned route are preferred so that course corrections (if any) are short.

Ries illustrates the same spirit of short feedback loops in the diagram below:

Feedback Loop

The aim is to quickly show something to the customer so as to seek his acceptance and then move onto the next iteration to add some more features or perhaps remove some existing feature based on the feedback received. Ries puts it eloquently, “…the goal of the MVP is to begin the process of learning, not end it. Unlike a prototype or concept test, an MVP is designed not just to answer product design or technical questions. Its goal is to test fundamental business hypotheses“.

While the entrepreneur is incorporating feedback and working to improve the product, how does he ensure that he is on the right track. This is where innovation accounting comes into play. It comprises of prioritising product features, selecting a target market, and critiquing the vision in the light of market feedback. Innovation accounting has the following steps:

  1. Using an MVP to have a firm grasp on the current position of the startup
  2. Trying to move this baseline to where the startup would like to be by tuning it up
  3. Finally, arriving at a decision on whether to pivot or persevere

The entrepreneur should be careful in measuring the data lest he finds himself obtaining vanity metrics (that wrongfully depict the startup to be in a healthy or improving condition) instead of real metrics.

The above help the entrepreneur in deciding whether to pivot or persevere. While persevering is relatively easy to understand – iterating through the build-measure-feedback loop continuously while tuning the product continuously – pivoting requires a little explanation. Pivoting doesn’t mean throwing away everything and starting from scratch. It is about reusing whatever has been built to the extent possible and then building on top of it to target customers afresh. Pivots can be of one of the following types:

Zoom-in Pivot: what was earlier only a feature of the product becomes the product now and other features are either abandoned or assume lesser significance.

Zoom-out Pivot: the product itself is insufficient and thus more features are added to it to create a new product.

Customer Segment Pivot: the product solves a real customer problem but it would better serve a different customer segment than the one it is currently targeting.

Customer Need Pivot: the need being solved currently is insignificant as compared to the one that can be solved without repositioning too much.

Platform Pivot: this is a pivot from selling a product that solves a particular need to let customers use it as a platform for provide similar services.

Business Architecture Pivot: this is a pivot between high margin, low volume business (usually B2B) and low margin, high volume business (usually consumer products).

Value Capture Pivot: a different feature can be monetised instead of the one currently being so.

Engine of Growth Pivot: the company can pivot among the engines of growth – viral, sticky, and paid. This usually requires a pivot in capturing value as well.

Channel Pivot: a pivot in the distribution channel of the product / service.

Technology Pivot: the company can pivot on the technology that provides a better cost advantage or better performance

Continue to Part IV >>

How to Raise a Lean Startup – II

Lean Startup

<< Part I

Learning is the centrepiece of Lean Startup. So much so that the the progress of a Lean Startup is defined in terms of learning milestones and people are held accountable to the same rather than organising them in traditional departments and holding them accountable to individual responsibilities.

The real motive of an MVP is to generate learning. This is because more important than building something efficiently is building the right thing. No point building a great product with a greater process that no one desires. Thus learning helps in validating the hypotheses the entrepreneur makes when building his product.

This product is refined based on the feedback generated from the market through the use of MVP. In the face of this feedback, which might not always be positive, the entrepreneur, might have to decide whether to continue to work on the same product or choose a different strategy. But such decisions are less frequent than the tuning done to the product. Even less frequent, if at all, are changes to the overarching vision with which they set out to become an entrepreneur.


As Ries says, “…a startup is a portfolio of activities. A lot is happening simultaneously: the engine is running, acquiring new customers and serving existing ones; we are tuning, trying to improve our product, marketing, and operations; and we are steering, deciding if and when to pivot. The challenge of entrepreneurship is to balance all these activities.

Not just startups but even existing organisations need to learn and innovate continuously in order to maintain their competitive edge or gain one. In this ever changing technological landscape, such edges get eroded very fast. Consider Blackberry that had long enjoyed the image of a premium, enterprise mobile handset company. It had two major advantages over its competitors: push mail service and Blackberry Messenger. With the rise of smartphones and their numerous apps, both these advantages were laid to waste. The result, Blackberry’s share in the market, which has already reduced to a minimum, is shrinking rapidly. The company is desperately looking for someone to buy it out but nobody wants to.

There is a trap in trying to learn what customers want. An entrepreneur should be able to distinguish between what the customer is asking for and what he really wants. This is because a lot of times customers don’t know for sure what they want. Identifying the real wants and working on the same causes the startup to grow and evolve. This is what Ries calls Validated Learning.

The question is not “Can this product be built?” In the modern economy, almost any product that can be imagined can be built. The more pertinent questions are “Should this product be built?” and “Can we build a sustainable business around this set of products and services?” – Ries

Mark Cook, Vice President of Kodak Gallery says the same thing in his own words:

  1. “Do consumers recognize that they have the problem you are trying to solve?”
  2. “If there was a solution, would they buy it?”
  3. “Would they buy it from us?”
  4. “Can we build a solution for that problem?”

All the above is based on the cornerstone of experiments. I had read somewhere (I think it was Stephen Hawking’s “A Brief History of Time”) that an experiment cannot be considered a failure if it disproves your hypothesis. It’s a failure when it is inconclusive. Therefore even if the product fails, the experiment is still a success because we know what the customer doesn’t want.

Now, how to structure the experiment, the hypothesis. Ries considers two hypotheses to be structured: value hypothesis and growth hypothesis.

Value Hypothesis tests whether the product / service being built would actually deliver value to the customer. This hypothesis helps in answering the question would there be customers (early adopters) who would buy the initial versions of the product (MVP) and find it useful.

Growth Hypothesis tests whether the product’s purchase and usage would spread from early adopters to the masses. This helps in answering the question would the business grow from the initial success with early adopters.

Continue to Part III >>