0

I am a new PM/PO in a software firm in California. I am working with offshore team in India. As a new PM/PO I need to do Sprint Planning. As I understand, Sprint Planning is also known as Sprint 0 as nothing is delivered for customers or for internal teams to test/look into. As a PM, during sprint planning, I need to do the following: 1. Business requirements 2. Come with product backlog and user stories 3. High level vision and outcome we except 4. DoD for each story 5. Other materials.

***** Is my above understanding correct?

I was told that Sprint planning can take 4-8 weeks. Is this true? If yes, during this time, what would the development team do? Create frameworks, checklist and so on? or can they be pulled into other projects.

**** Does scrum master, PO, Dev team get into sprint planning?

We work in distributed teams how does one carry out the sprint planning given the time zone difference. Should everyone (scrum master, PO, dev team) get into a call (audio or video) to discuss product backlog and perform product grooming? OR can this be done via google docs where I throw in all the info and the dev and other stakeholders look into all this and make changes or leave comments. I feel latter (google docs) system would be inefficient.

***** Please let me know what is preferred.

2

As a new PM/PO I need to do Sprint Planning. As I understand, Sprint Planning is also known as Sprint 0 as nothing is delivered for customers or for internal teams to test/look into.

This is not correct.

Sprint Planning is a regularly occurring event. It happens once per Sprint and involves the entire Scrum Team. The purpose is to review the Product Backlog, determine what Product Backlog Items can be completed in the Sprint (basing this on a forecast of the team's capacity and any kind of prior performance data - this gets better over time), and starting to further decompose the work and develop a plan for achieving it. The outcome of a Sprint Planning is a Sprint Goal and a Sprint Backlog.

Sprint 0 is not an official part of Scrum, but it roughly correlates to what other models call, among other things, inception. This includes work such as forming the team, defining the initial scope, identifying an initial architectural strategy, developing release strategies and plans, aligning on a common vision, and related activities to align the team with the product, a portfolio that the product is a part of, and the broader organization. Unfortunately, Scrum does not have an explicit way to handle these activities.

As a PM, during sprint planning, I need to do the following: 1. Business requirements 2. Come with product backlog and user stories 3. High level vision and outcome we except 4. DoD for each story 5. Other materials.

Some of these things should be done well before a Sprint Planning.

The definition of requirements and capturing them as Product Backlog Items (in an appropriate format, which may or may not be User Stories) is an ongoing activity. The refinement of the Product Backlog is also an ongoing activity for the development team and the Scrum Guide recommends allocating about 10% of the Development Team's capacity for refinement. This type of work is probably a full-time job for the Product Owner.

The Definition of Done is not typically defined for each story, but rather a set of criteria that is applied to each Product Backlog Item, plus the Sprint's Increment as a whole.

I was told that Sprint planning can take 4-8 weeks. Is this true? If yes, during this time, what would the development team do? Create frameworks, checklist and so on? or can they be pulled into other projects.

A Sprint Planning event is defined as being "time-boxed to a maximum of eight hours for a one-month Sprint" and "the event is usually shorter" for shorter Sprints.

However, with respect to inception activities, a survey from 2013 ran by Scott Ambler found that the average agile team spent about 4.6 weeks in inception activities. I would say that 8 weeks would probably be pretty excessive, but roughly a month wouldn't raise any serious concerns. It would depend a lot on the environment and contextual information, though.

Does scrum master, PO, Dev team get into sprint planning?

Yes - Sprint Planning involves the entire Scrum Team.

We work in distributed teams how does one carry out the sprint planning given the time zone difference. Should everyone (scrum master, PO, dev team) get into a call (audio or video) to discuss product backlog and perform product grooming? OR can this be done via google docs where I throw in all the info and the dev and other stakeholders look into all this and make changes or leave comments. I feel latter (google docs) system would be inefficient.

Having people be online and having discussions is the preferred option, not only for Sprint Planning, but all of the Scrum events.

  • Thanks for the clear explanation. so where does release planning feature? Is iteration planning and sprint planning one and the same? – SPO Nov 13 at 22:36
  • @SPO Iteration planning and Sprint Planning are the same things. Scrum just happens to call iterations "Sprints" and therefore has a Sprint Planning event. As far as release planning. In the context of Scrum, every Sprint should produce an Increment that could be released, if demanded. The Sprint Review can provide a good opportunity to check the current state of the product and determine if and when a release is appropriate. – Thomas Owens Nov 14 at 2:06
0
  1. Your understanding is correct. But sprint planning does not take 4-8 weeks. One sprint is created for 1, 2, 4.. weeks, before stating each sprint you need couple of days in order to plan your sprint. When you are planning, for example, 2nd sprint your development team works on 1st sprint. It means you should prepare everything beforehand.
  2. In my case scrum master, PO, Dev team all get into sprint planning because it helps me a lot and very effective.
  3. About timezone difference, PM/PO should manage daily conference calls, stand-ups between team members where everyone reports what he/she has done, doing, and will do during the working day. In this case, the team will be more sync even if works in different time zones.
  4. I recommend you not to make one general document in google docs for both the dev team and stakeholders. It is better to keep two separate documents, one for the internal team and one for external stakeholders.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.