Category: planning

The Problem With Planning

September 16, 2009 by Kelly Waters

Hi, this is Kelly, from Agile Software Development Made Easy!

I think I've been pretty successful in my career. But if I was better at planning, I wouldn't have achieved half the things I've achieved in my career! In fact, I wouldn't even have started some of them...

In reality, there are some things you can plan, and some things you can't. The trouble is, in most organisations we've come to expect a plan. And to meet it whatever happens. And that's just not realistic.

My Agile Team: More Code, More Problems

March 16, 2009 by mattgrommes

Welcome to the newest installment of My Agile Team, my team's ongoing series of misadventures in trying to get better at Agile development. This time around, we're still playing Whack-A-Mole on the list of bugs we've encountered since Go Live. We stomp one out, another pops up.

What I'm going to discuss this time is our approach to trying to fix these critical bugs while maintaining at least a semblance of our Agile nature. It's hard to do a planning meeting and decide on what to work on when you've got new things popping up and old things dragging on. Read on for more on how we're planning in the midst of firefighting production bugs.

Planning - how we really do it in practice

March 13, 2009 by Jack Milunsky

Introduction
In this article I describe how we do sprint planning at our company with teams of about 10. I take you through a detailed account end-to-end process and cover all the major points.

The importance of planning
Planning the sprint is where it all starts and so it's really important to get this right. It's the foundation on which the next two weeks (in our case) worth of work is based, and without it the sprint falls apart. Set the team up for success by investing the time needed to come up with a well thought out plan. Trust me, it's worth it. (Read more...)

Accounting for bugs the agile way - part II

March 6, 2009 by Jack Milunsky

Last weeks post struck a cord with readers and as a result I got some really good feedback. Based on the responses I decided to use this week's spot to clarify my position on some of the issues as I see them.

I believe that ...

1. Teams should do whatever they can to fix bugs that are found during the sprint in which they're found. The definition of "Done" means the feature is coded to standards, unit tested, functionally tested, documented and all known bugs are resolved during the sprint. If you postpone bugs, what seems trivial at first will mean significant build up of technical debt which you will need to pay for downstream.

The Effective Sprint Planning Meeting

January 14, 2009 by Peter Stevens

At the beginning of each sprint, the Scrum team and product owner negotiate the scope of the sprint. They have a limited amount of time to discuss and agree on the sprint backlog. The product owner wants functionality implemented properly and to invest development dollars wisely. The team wants a mandate it can fulfill. And everyone wants the meeting to finish on time! Here is an agenda (complete with a downloadable template) to follow so that your sprint planning will be successful.

My First Agile Project Part 5: Our Top 5 Agile Mistakes

September 29, 2008 by mattgrommes

In the previous parts of this series (1, 2, 3, 4), I went into a lot of the initial issues of how we ran our project and some of the things we did wrong. For Part 5, I'm going to focus on the 5 big mistakes we made in the project before I move onto another phase of the series.

For some background, the project was to integrate an off-the-shelf (but highly customizable) billing system to replace an aging custom Oracle forms app. This was our company's first foray into Scrum and Agile as well as the first Agile experience for most of the development team. After we sailed past our second management-imposed deadline I started thinking about how we could correct our process for this project and the next ones we do, which led me to write it all down in this series. Keep reading for the Top 5 mistakes we made (in no particular order). Where possible I also give some detail about how we've worked on correcting our process. I hope this list helps you avoid these mistakes and make your own all-new ones. :)

Predicting the team's Velocity: yesterday's weather method

September 25, 2008 by Przemysław Bielicki

"How much software will you deliver in the next Sprints/iterations?" - do you often hear such questions? I do. And this question is really valuable especially for the project/product sponsors. But not only management likes knowing how much software they will deliver in the upcoming Sprints. Everybody (including development team members) likes to know the answer for questions like: "Where we will be in three months from now?".

If you track your team's Velocity you are able to answer such questions somewhat accurately, which is great. I personally don't know better tool for answering presented questions than tracking development team's Velocity.

Let me now explain how you can compute how much software your team will deliver in the next Sprints basing on the current team's Velocity.

My First Agile Project Part 2: Inception & Planning

September 10, 2008 by mattgrommes

In the first part of this series about my team's first Agile project, you read about some of the mistakes we made in only doing 80% of Scrum. In this part, I'll talk about the initial Inception Phase of the project and about our Sprint Planning meetings. As usual, we did some things right and did some things we hopefully won't do again. I'd love to hear in the comments how our experience compares to yours.

Sample Sprint Planning Procedure

May 13, 2008 by Artem Marchenko

The adaptation mechanisms built into the Scrum process allow for many modifications and adjustments in the sprint planning procedure. Different variations work for different teams and environments. Here is one of the variations that I find useful:

Preconditions

Product backlog contains a set of user stories sufficient for at least 2-3 sprints, ideally - for the whole current release and more. The team together with the Product Owner and possibly with some stakeholders went through the top stories 2-3 days earlier. As a result for a sprint or two there are enough reasonably small and well understood top priority product backlog items.

Advertisement:

Epics and Themes

May 6, 2008 by Artem Marchenko

User Stories are a not mandatory, but very recommended part of Scrum and eXtreme Programming methods. Most of people acquainted with agile software development feel comfortable with the requirements written in the form of "As a [user role] I want to [goal], so that [reason]". Less people are acquainted with epics and themes usage.

Terms

Epics are just huge stories for capturing relatively low priority requirements that are often too complex to estimate right away and that are going to be detailed later. An epic for a car could be "As an environment conscious driver I want to be able to use both gas and hydrogene". A theme on the other hand is a set of stories grouped around some functional area, user group or anything else that makes sense for the product owner. Themes are often confused with epics, because quite often the epic is split down into exactly one theme. A theme for a car could be a set of stories grouped around the building the hydrogen engine.