0

We are using Visual Studio Team Services to host our code in a Git repository and to manage our Agile planning through iterations (sprints), user stories in a backlog, a taskboard for the current sprint, etc.

This works really well for planning and executing the current sprint and for reviewing the previous one, but I am finding it difficult to get an overview. I'd like to see all the sprints laid out between now and release, look at which user stories are important in each of those sprints, ... i.e. jump up a level and plan all the sprints.

Where does that fit in the Agile methodology and do the VSO / TFS tools support me beyond the backlog list of user stories?

  • 3
    Long term planning and agile? – user40980 Mar 14 '16 at 15:08
  • 2
    Asking for tooling recommendations is off-topic due to the fact that the knowledge doesn't age well. A new, great tool could come into existance next month, or a well-liked tool could stop development, making the answers very nebulous. – Ampt Mar 14 '16 at 15:18
  • 1
    Ugh...using something like Microsoft Project is going to pull in exactly the sort of overspecificity that cause problems in non-Agile models. The moment you get beyond high-level lists of stories per sprint, you might as well just give up on Agile, because you are not doing it. – Steven Burnap Mar 14 '16 at 17:02
  • 1
    How far out do you plan sprints? Do you redo everything when something has to get pushed back? That's a lot of work to have any agility in a project. – JeffO Mar 14 '16 at 22:04
  • 1
    You may be able to leverage Epics and Features to get the view you're looking for. – RubberDuck Mar 15 '16 at 1:05
6

The bits of this question that aren't around tooling are well answered in this question that @MichaelT already pointed to.

Agile is opposed to over-planning

As far as tooling to support long-range planning, though, the key point is that Agile recognizes that business conditions always change, and that long-range plans rarely make it to the end without significant change. Most organizations overplan, and waste huge amounts of time planning in great detail what will happen six months out, only to replan in three months, and in five months, etc.

Keep long-range plans high-level

Of course you have to do some long-range planning in any significant project, but the key is that because you will be replanning anyway, you should keep your plans high-level. Don't waste time making pointless estimates by the hour of what you are going to be doing in six months. Managers love to do this because it makes them feel in control, but it is an illusion. Unfortunately, many traditional project management tools lead you into doing exactly this.

Ideal case

In the idea case with Agile, you don't have a "deadline". You have a list of stuff you are going to do, and you release every sprint. The software is "done" when you get to the point where stakeholders say it is done. Your plan is the backlog. That's the list of the things you currently expect to do in the order you expect to do them in. Planning is just writing stories, and organizing them in your backlog. No extra tools are needed.

Realistic case

Of course, realistically, you are not working in this fantasy land as normally the suits want to know when it will be done. (Or worse, are telling you when it must be done.) Realistically, some sprint results are pointless to release while others are vital. Realistically, you will have other teams that need some of your stories finished before their stories can start.

In these cases, you will probably have to create a list of future sprints, and slot stories in each sprint, so you have a rough idea when you'll "finish".

The key: That is all you should do. Anything else is overplanning.

Tools

Given that, the results of your planning is just a list of sprints, with a bulleted list of stories for each sprint. That's it. Any tool that supports bulleted lists and tables will do. You could use Word. You could user PowerPoint. You could use Sharepoint. You could use Mediawiki. (My team uses Confluence.) You could even use a whiteboard with lines per sprint and sticky notes. (I've seen successful teams at my company do exactly that.)

Just don't do waterfall planning (and use waterfall planning tools), label milestones "sprints", have a daily scrum and pretend you are doing Agile.

1

I'd like to see all the sprints laid out between now and release

Sounds like you are doing scrum, in which case you release (or you can release) at the end of every sprint. If by release, you really mean the project is all done, then you shouldn't be looking at your sprints that way.

You should have a roadmap from the product owner that is shared with everyone. This should cover high level features or direction of the product. The only timelines included should be general targets to help identify priorities. The essence of agile is knowing that things will change and that those timelines are not real.

You should not be looking more than one sprint ahead, since this sprint could change everything. You likely will have an idea of the next sprint, since you will know what was left at the top of the backlog. You should not be worried about planning any sprints further out than that.

  • 1
    I've recently heard a very simple explanation for why this is more true in software than elsewhere: software can be trivially copied and reused. If you could reuse something, then you probably would. Ergo, the fact that you are developing software means that you are solving a problem that nobody ever has encountered before. That's why estimating and planning is so hard in software development. – Jörg W Mittag Mar 14 '16 at 22:32

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.