An ordinary time schedule?
Hi everyone! I have recently become involved with Scrum and I'm very enthusiastic about it. It's a life saver. I intend to use it for my final year project but my instructor has asked me to provide him with a monthly schedule of what is to be done every month. My first initial approach was this:
November 2012:
Documentation needs, prioritizing and sequencing feature cards, plan n iterations,
get scope to 80%
December 2012:
Iteration n-1: Requirements, Design, Development, Customer Preview, Test.
Adapt: Re-plan.
Early prototype
January 2013:
Iteration n-2: Requirements, Design, Development, Customer Preview, Test.
Adapt: Re-plan.
April 2013:
Adapt: Final integration
April 2013:
Go live
As you have understood I can't submit any Scrum artifacts. He just needs a simple schedule with tasks. But how do you present a simple schedule that makes sense to people who don't know Scrum and are more used to waterfall methodologies?
Thank you for your feedback. The advice of experienced professionals is very useful to me and I appreciate it.
What pieces of functionality do you foresee delivering in each iteration? Find a way to present that information to him/her. You might even share how you plan to do so in the first sprint. Of course, after sprint 1 you'll have new insights and probably need to send him another revision of that plan.
Those last two items would make me nervous: Final Integration and Go Live. That's an awful lot of hardwork put to the test at the last minute. What kinds of crazy things can you concoct that practice those two things earlier?
What is your project focused on if you don't mind sharing?
Hi Zoe,
in addition to Ryan's advice I suggest you create a Product Backlog, which focuses on delivering working (and done) functionality. You can chop down this Product Backlog into Sprints, which might reflect your monthly planning situation. However, you will be better off with shorter Sprints. You might also want to include some planning items each Sprint, which reflect the time you need to adapt to new insights.
Take special care about Ryan's hint of integrating constantly and early. There are companies failing out there because they don't heed that advice.
Best
Dominik
To add to Ryan's reply, I would suggest you find ways to start integration in earlier iterations by providing maybe more basic functionalities sooner and more complete functionalities in the next iterations (in an incrmental manner). Not a critic but having sequence of sprints like 1- Documentation, prioritization, plan, 2- Iteration 1 - Prototype, 3- Iteration 2 - Product rel. 1, 4- Final integration and go live, it is still sounds a bit like waterfall paradygm.
For the communication aspect, I would suggest you start change as soon as you can and discuss SCRUM approach with your instructor. By trying to give him what he used to have will not force minset change in the organization.
Hi everyone. Thank you again for your valuable feedback. Indeed, after reading Ryan's comment I focused on the product backlog and I planned a 21 day window for four sprints. I really felt I had no idea what I was doing. It was an overwhelming process. :) I can't agree more with all of you. Dominik and Michel, you are right, I should start with basic functionality, then add up - shorter sprints. Instead I have the four "waterfalls" (or should I say skyfalls??) over my head. :) I've read many books about Scrum and Agile but I was never part of a team that used Scrum and there are no mentors around. :) How did you learn Scrum?
First, by reading books like you but practicing aspect is missing. There are courses where you can go through more practical exercises that could help to avoid pitfalls. Probably, you can be able to find some good courses near to your local area. Often, SCRUM training organizations also offer mentoring services.
And the last but not the least, try it and adjust (which is the basis of SCRUM by itself). You can inspect and adjust at each sprint and this also includes the way you use SCRUM framework.