It’s a good idea to plan what you are going to deliver in a release.

It’s a great idea to outline when you are going to start these features in your sprint cycles to give people an idea of when work will start.

Not working with a new API from that group until Sprint 4? No need to ask questions about it in Sprint 3.

Working this way has the benefit of taking the stress and load off your team as they are not worrying about everything being on fire and starting on the same day. They can focus on what they are doing now, knowing that they will get to that stage at some point.

What is a very, very, very bad idea is to develop a plan to deliver and release code, only to throw it out the door in Sprint 1 and ask when everything is starting and go against what it is completely.

That adds unneeded stress to your project, unneeded anxiety and ceremoniously throws out all that great work you “were” doing ahead of time.

Want more? Check out my book Code Your Way Up – available as an eBook or Paperback on Amazon (CAN and US).

Want more? Check out my book Code Your Way Up – available as an eBook or Paperback on Amazon (CAN and US).  I’m also the co-host of the Remotely Prepared podcast.

Author

Write A Comment