Posts tagged ‘scrum’

February 14, 2013

Definition of Ready for Sprint Planning meetings

by Sampath Prahalad

Nice video on How to improve Sprint planning.

One of the tips given is to have a Definition of Ready.
Only those user stories that are ready to be presented are discussed in the Sprint planning meeting. This ensures that the Product Manager does his home work on the user stories to be taken up in the Sprint. This also reduces the time taken for the Sprint planning meeting.

See the video below for some good tips.


January 5, 2013

Progressive elaboration of user stories

by Sampath Prahalad

Progressive elaboration of user stories just means that big user stories are broken down into smaller ones and filled up with more detail when they appear closer to implementation. This video below from Rally explains the progressive elaboration of user stories in an iceberg metaphor and also brings in a water line. Quite interesting.

November 29, 2012

Documentation updates in Scrum projects

by Sampath Prahalad

Scrum and other flavors of Agile expect a potentially shippable product at the end of each Iteration or Sprint. This typically means that each user story within the Sprint has to be developed, integrated, tested, documented and made deployable to production. While this is not new, I have seen many variations to this in my experience with Agile teams. I am going to deal now only with the Release documentation part here. Everything else is out of scope for now.

Consider the scenario below. In a reasonably small organization, we have the Product Marketing manager Laura who doubles up as Product manager of a desktop application GoldSpot that back-ends with a database server. Laura is responsible for pretty much everything on GoldSpot. She is always seen juggling and shuffling between business case evaluation, wire-framing, product backlog creation and constant prioritization, user acceptance testing, creation and updates to user and admin documentation, customer demos, marketing communication, etc. The product development team consists of 3 developers, 2 test engineers and a Scrum master. The team and Laura meet over Skype for the Sprint planning meeting, the daily stand-ups, Sprint review and retrospectives. The team is in their third Sprint, have just created a prototype worth showing to customers and have 3 more Sprints to go in this Release.

read more »

October 14, 2012

5 steps to get your team Agile

by Sampath Prahalad

At 5pm on a Tuesday evening, Greg and Anand meet up  at Cafe Pascucci in the city. Anand had  called up Greg earlier in the day and said that he needs to urgently meet him for some expert advice. Anand seems quite worried and Greg tries to put him at ease.

A little background here before we continue. Anand, a project manager has recently attended a Scrum Master training where he got introduced to Agile and Scrum. He works for Espresso Corp where he heads a product development team. Greg  is a seasoned project manager with rich experience working with teams and organizations of all types and in short has truly “been there and done all of that”.

After ordering for 2 cappuccinos and the initial pleasantries, Anand starts talking about his problem at hand.

Anand: “Greg, Thanks a lot for making it here on such a short notice. We recently had a product release in my company which was developed in the sequential waterfall model. The product fell short of internal and external expectations and we have had a lukewarm response to the product. After a Release post mortem and some brain storming, we feel that our rigid approach of baselining the requirements up front did not allow  us to react to competitors. Also, the product was ready for sales and customer viewing only at the end of the Release and we could not get any real feedback.
Now, I have been asked to set things right and make a release within 3 months which would meet expectations of existing customers and hopefully get us new customers.  As a company, we have a fair idea of the features to add and the areas to improve. We also have the skill set needed to get cracking on these. Since this is a make or break for the company and the people involved, I am very keen to get things right.
I feel that moving the Product development to Agile in general and Scrum in particular would set the problem right. I would like to draw from your vast experience here to know how exactly I should go about doing this. Let me know what you think.”

Greg took a sip from the coffee, thought for almost a minute and said: “Anand, you have identified the problem well. However, I am not sure if Scrum would be the answer to all your problems. There could be other tweaks needed. Before I can help you out, I would like to know a couple of things more. Who provided the requirements for the previous release?”

Anand: “We had a set of people from the Marketing team who created a PRD, reviewed and baselined it”.

Greg: “Once that was done, were there no changes at all?”

Anand: “Very minimal. Only 3 changes over the 6 month project duration, I think. The change control board voted against the other changes”.

Greg: “I am not too surprised. And did the Product Manager not fight back in favour of the changes?”

Anand: “The product marketing team… “

Greg: “There seems to be your first problem. It looks like the product did not have a dedicated Product Manager. Am I right?”

Anand: “Yes. The stakeholders from Marketing owned the PRD document of this and other products as well.”

Greg: “You are facing the straws effect where a lot of people are providing inputs from different quarters and no one person is completely responsible. This also confuses the development team. Change it to the funnel effect by getting a dedicated product manager who gathers inputs from various quarters and funnels them to the team.”

Anand: “Now, that makes absolute sense. A single dedicated person who collates all requirements from different sources and also keeps a tab on the progress of the product development”.

Anand starts taking notes.     1. A dedicated product owner for the product

Greg: “Next, get the team and this dedicated product owner trained on Scrum”.

Anand: “I have already done that. As we speak, they are all attending a 1 day Scrum training.

Greg: “That is good. However, note that the training might not be enough. You will need a coach to walk with them through the first couple of Sprints”

Anand: “I did not think of that. Let me factor that in”

Anand notes down     2. Scrum Training and a coach to walk through.

Greg: “This is another thing that I have seen working well in Scrum teams. At the beginning, come up with a list of rules for each of the Scrum roles. These essentially list the responsibilities of each role. However, it really helps to define it explicitly so that each person knows his and the other person’s responsibilities. For example: The team shall demo a story as soon as it is completed. The product owner shall not alter the scope of the Sprint once it has started. The Scrum master shall ensure that the team is protected from external interferences and scope change.

Anand: “That makes sense too. This way, each person in the team knows what is expected of them. When should I start the first Sprint?”

Anand adds this one too.     3. Rules for each Scrum role

Greg: “That is a good question. We are in the middle of the week. Start it from next Monday. However, I would suggest that you start
the daily stand-ups from tomorrow. Let the team start meeting at a common place and talk about the initial investigations and ground work that they have done. The silos will break down and team camaraderie will set in. It will also give the Product owner a chance to get the backlog ready for the first Sprint”

Anand: “I am really glad that I met you today. Now, how do I manage this team?”

Greg: “You bring an interesting point. Managers in Scrum are facilitators. Ensure that you do not turn their stand-ups into a lengthy status meeting. You have to let go of your command and control mode and be ready to enable them by being the process champion, resolving impediments and helping them self organize.”

Anand is busy writing     4. Culture shift: Let go of Command and Control mode

Anand: “Hmm. I have made some notes. Anything else that I have to take care of?”

Greg: “One last thing, get the team and product owner to define the Definition of Done.

Anand: “Yes, I will. The definition of Done actually refers to constraints, environments and guidelines which are specific to the product and not the user story, right?”

Greg: “Absolutely. I think that you are all set. Try not to deviate much from the few processes that Scrum prescribes, fine tune  the process as you go and feel free to talk to me whenever you need.”

Anand finishes writing down and lifts his head up.     5. Define the Done criteria .

Anand: “Thanks Greg, I definitely will keep you posted.  Cheers.”

Greg: “Cheers. All the best. Have a great evening”

Anand: “You too. I feel quite relieved and upbeat. Thanks, mate.”

Related Links

How Agile generates value
New to Scrum? Here are the Scrum Rituals
What does the Scrum Master manage?
How can managers effectively contribute  in Scrum?
Key traits for a successful Agile Product Manager
Product Managers, measure thyself
My competitor, my friend
Product management: 3 unwise monkeys

Pictures courtesy:, Bluepod coffee company

July 6, 2012

Inspect and Adapt for Agile Product Managers

by Sampath Prahalad

As organizations make their movement from Waterfall to Agile software development, a shift in culture takes place. One discipline that is most affected in this whole change is Product Management. They have to cope up with the demand for more releases within the same time and each release has to have meaningful content.

I have tried to list the traits needed for a successful Agile Product Manager here.

  • The clarity for the near term goals along with a vision for the medium term.
  • The ability to constantly prioritize and groom the product backlog so that the most important business requirements are placed at the top.
  • The ability to split requirements into granular user stories so that they can be completed within a Sprint.
    read more »

July 4, 2012

Bye Bye AgileIndia2012, Welcome AgileIndia2013

by Sampath Prahalad

I attended Agile India 2012  in February this year. Three full days of talks and discussions about different streams within Agile (Agile Product Management, Agile Testing, Agile Coaching, etc), the different flavors of Agile (Scrum, Kanban, very little of XP, etc). Many talks were great,  tweets and related blogs were nice. There was enough food for thought and for the tummy as well. I made new friends and met up with lots of friends and like minded people. Here are my experiences from day 1, day 2 and day 3. So, Agile India 2012 was a success by any yardstick, the organizers deserve many pats on the back for organizing and pulling off an event of such a magnitude. They had done their due diligence and it showed.

Now, here comes Agile India 2013 . I don’t want the 2013 version to be a similar success, I want it to be much bigger and better. Yeh dil definitely maange more (Translates to ‘The heart yearns for more’)

For this, there are some tweaks and changes that the organizers need to make. I have tried to list some of them here.

read more »

June 22, 2012

Agile Estimating over a coffee and 3 glasses of water

by Sampath Prahalad

Joseph Flahiff of Whitewater Projects explains about Agile estimating in layman terms by using 3 glasses of water. Ignore the background noise. This really is a nice video. Keep them coming Joseph.

read more »

April 23, 2012

Scrum rituals, summarized…

by Sampath Prahalad


Happens on

What gets done



Sprint planning meeting

First day of the Sprint

  • The capacity of the team for the Sprint is determined.
  • User stories for the sprint are presented by the PM, and agreed upon between the team and the PM based on team capacity
  • The team then breaks the User stories into tasks and assigns the tasks to themselves.

Sprint planning meeting is complete only when both the above are Completed

  • If there is an investigative User story, a specific time period (maybe a week) is alloted to that with the aim ofcoming up with the next steps.
Once planned, the contents of the Sprint are to remain constant for the duration of the Sprint. Any recurring activities like Production Support can be put in as a separate user story or their effort need not be tracked as part of the Development sprint.


Daily Scrum meeting

Every day of the Sprint

3 questions to be answered by the team.

  • What did you do yesterday?
  • What will you do today?
  • What impediments do you face?
This is not for the managers but for each other. If it is becoming a status meeting, the manager can be asked not to participate


Sprint Review / Demo

Last day of the Sprint

An informal demo of what was achieved by the team to the Product manager and other stakeholders in the Sprint. Anyone in the Delivery team can give the demo. The Sprint review focuses on the product and not the Process

Only User stories that are developed, tested and ready to deploy are ones that classify as Done.


Sprint Retrospective

Last day of the Sprint

The team (minus the managers) reflects on what went well during the Sprint and what processes can be changed for the better.

Continuous process improvement.

The Sprint Retrospective focuses on improving the Process and not the Product.


User story Sizing (Optional but recommended)

Once every 2 (or 3) weeks

Sizing of the user stories in the prioritized backlog list. The PM and team go through the user stories, play the planning poker game and assign story points to the user stories. Pace: 6-10 user stories per hour. The Intention is to have a backlog that is prioritized and well sized at any point of time so that the PM has enough information ahead of Sprint planning to identify the user stories that provide the most business value.
%d bloggers like this: