Project planning for an Agile development

Robert Poddar

Hi, 

I would like to understand how do you prepare a project plan for an Agile software development. I understand that first the product backlog needs to be created containing the list of features/bug/enhancements that are needed for the release and subsequently during the Spring planning, the tickets are discussed with the PO and understood and then story pointing is done. After they are "pulled" by the team into the Sprint. 

My questions: 

1. How does one prepare a project plan at the beginning of the project, since management would like to know the release date of the deliverable. 

2. As Sprints are being developed, the project plan is updated? meaning that the plan is prepared for the 1st Sprint and once this is done, then during the 2nd Sprint planning, the project plan is updated. Is this understanding correct? 

3. If point 2 is correct, then there isn't any way to indicate upfront a release date. I assume that there isn't any notion of Baseline v/s Actuals (like how it used to be in a waterfall development). 

thanks 

Robert.

 

Betsy Green

Hi, Robert.

When you say "Project Plan," do you mean schedule?

Robert Poddar

Hi Betsy

 

Yes, by project planning i meant by schedule planning..

Betsy Green

This is where an agile approach gets tricky for those of us used to waterfall (me). 

The latest edition of the PMBOK describes two approaches:

• Iterative scheduling with a backlog - which it sounds like what you're attempting
  • Requirements are documented in user stores, which are prioritized right before they're developed
  • Features are created in sprints
  • Ideally, some of those deliverables can be completed and given to the customer as you go along, instead of everything being done at once
  • Where your schedule would come in would be in working with the dev team to determine what's in each sprint and how long each one will take to complete. From there, you'd be able to come up with some kind of schedule.
  • So, it's more like, "Hey, we're releasing stuff every three weeks. Here's what's planned to be in each release."
  • The schedule WILL be iterative. It's just not going to work like schedule management does in a waterfall environment.
• On-demand scheduling, using Kanban, which looks a whole lot like the Card view in Smartsheet.
  • Work is put in a backlog or queue as resources are available
  • You'd maybe get an estimate as each queued deliverable is prioritized 
  • This works better for incremental changes
  • This is like, "Here's a list of stuff that needs to be done. Good news - Sarah is available to create this feature, and it'll be done in two weeks."

I'd be very interested to see how other people tackle schedule management in an agile environment. I have not had much success with this approach yet, though I am open to the idea.

 

--Betsy

Robert Poddar

Hi Betsy, 

Yes, you are right. Coming from a waterfall background, it is very difficult to put a project schedule/plan in place. I have been going through some articles, videos and this is what i have understood; but i am not 100% sure if this is how scheduling needs to be done. 

1. Tickets for the release are into the product backlog. 

2. During the Sprint planning, the tickets are scrubbed and estimated. The team decides on the tickets that will go into the Sprint and the Sprint duration is identified. 

3. At this point, the project schedule / plan will indicate the list of tickets that have agreed by the team in Sprnt1. 

4. Once the Sprint is completed, the residue tickets will move to the Backlog / next Sprint. Once again the next set of tickets are taken up and scrubbed & estimated. The schedule / plan is updated accordingly. 

If this the "right" way / method to prepare the schedule, then one thing is that there isn't any Baseline concept in Agile. If there isn't then the project manager cannot track the plan v/s actual. 

If this is the case, then is it ok if the PO indicates a date when he would like a release and the team works on the tickets to meet that date? As the team goes along, some non critical tickets may need to be dropped in order to meet the release date. The project schedule / plan will not be a reference tool, but a tool for the actual work done, across how many Sprints. 

For future similar project, we use the project schedule / plan to indicate how many months it has taken the team to make a release. 

I too am interested to know how Smartsheet community and the Smartsheet team has been preparing their respective project schedule / plans.. Hope to get some help.. 

Jibran Ahmed Sheikh

https://community.smartsheet.com/discussion/comment/95286#Comment_95286

Amazing. Properly explained.