Skip to content

Category: ScrumSyndicate content

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

September 25, 2008 by Przemysław Bielicki


Picture courtesy of aloriel@flickr

"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.

Creating the Scrum Product Backlog: Start with the Users!

September 24, 2008 by Peter Stevens

When defining a product, it’s easy to write down list of features and call it the product backlog. It’s much harder to build a product which so deeply and profoundly meets the needs of its users that they just have to buy it. An agile team can use a three workshop process to create the Scrum product backlog. Workshop 1: Identify the users. Workshop 2: Figure out what they want. Workshop 3: define the feature mix which will get you to a product that the customers want as quickly as possible. Let’s start with Workshop 1, the Users.

My First Agile Project Part 4: How to lose credibility and jeopardize your project with lack of management buy-in

September 22, 2008 by mattgrommes

Picture courtesy of shaz wildcat@flickr

Welcome to Part 4 of My First Agile Project. If you haven't read the others in the series, don't worry. Each part should stand alone. If you want to read the whole story though, the other parts are available: Part 1, Part 2, Part 3.

In Part 3 of this series, I talked about our demos and I mentioned how they unfortunately turned people off the demo with presentations about mostly behind-the-scenes features. My first instinct was just to say that those people lost their right to have input since they weren't involved in the demo. In reality, the business world just doesn't work like this, much to my chagrin.

What happened was the people who didn't care to come to the demos just came later with changes and "suggestions" for new work we had to do. Also, since a lot of the ones who were supposed to be coming were upper management, their lack of knowledge about the Agile processes we were using led to a lot of problems and misunderstandings later in the project. Read on to hear more about how we failed to get our management on board as much as we should have. Hopefully you can avoid that mistake and some of the problems we've faced.

How to get your agile project approved

September 17, 2008 by Peter Stevens

There are three prerequisites for starting a project under Scrum: a product owner, a product backlog and a team to implement the features. Is that enough to get a project approved for development? Probably even an agile company will want some basic questions answered: What are we building, and why? How much will it cost? How long will it take? Here's a way to move forward.

My First Agile Project Part 3: Viral Videos and Bad Jokes in Scrum Demos

September 15, 2008 by mattgrommes

Picture courtesy of karindalziel@flickr

Welcome to the 3rd part of my series on my first agile project. This time, I'll be talking about every introverted programmer's favorite part of Scrum, the end-of-sprint Demo. More specifically I'll talk about how we cracked wise, showed internet videos, heckled each other, annoyed our management, and occasionally showed off the work we had completed during the previous sprint.

Even though we usually dreaded them, our demos almost always went off okay and we all came out alive. If you're not familiar with them, the demo is where the team shows off the work they've done during the previous sprint. We were doing 4 week sprints so we usually had quite a few things done by the demo. It's sometimes the first chance your teammates have to actually see what you've been doing and to to catch up the rest of the team in a more concrete way than the daily stand-up meeting. It's also where you're supposed to get the feedback of the stakeholders and customers involved in the project. With our billing application project, we were interacting with a bunch of different departments in the company so we had a lot of stakeholders. In theory, all of these people will see the product and give feedback. In reality, this doesn't always end up working like you'd hope. Getting your demo right is much more important than we initially thought.

My First Agile Project Part 2: Inception & Planning

September 10, 2008 by mattgrommes

Picture courtesy of ghindo@flickr

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.

The Big Development Project: How much should it cost?

September 3, 2008 by Peter Stevens


Picture courtesy of irene.@Flickr

Some people think that agile and budgeting are incompatible. The product is ready when the product owner says it is. But before starting a project, most managers want at a least budget. So the product owner puts together his wish list and asks the ScrumMaster what it will cost to build. The answer comes back — usually a long time and whole lot of money! Then the customer turns pale as he tries to decide what it will really cost, whether he can afford it and whether it's worth it.

But there is a better way: the product owner can perform a double worst case analysis. This quick and easy tool uses the project's business value to determine a reasonable price for the software investment.

My First Agile Project, Part 1: Doing 80%

September 1, 2008 by mattgrommes

This is the first in a series of posts on what I've learned about how we're doing (and not doing, as I've learned) Scrum on a big project at my work. Going to the Agile2008 conference and reading Mike Cohn's Agile Estimating and Planning have really helped me understand how we got into the predicament we're now in, with a late project and diminished team credibility with our upper management. Hopefully our story will help other teams on their road to becoming Agile.

We were brought Scrum by the vendor of the new billing system we were integrating. They use it internally and taught us about the practices. Immediately, it was a hit. We all liked the iterations, taking on tasks, demos, etc. Except the day-long planning meetings (we were doing 4 week iterations and have ~10 people on the team so that's a lot of estimating and assigning) we liked the whole process. I had complaints very early about the seeming lack of involvement from upper management but we dismissed it at the time, thinking they would come on board later. I gave a presentation at one of the demos about Scrum, having been told that some of our senior management team would be there but they weren't. The project seemed like it was going along fine though, so we just kept going.

Third Annual State of Agile Survey Data Available

August 29, 2008 by martinig

This survey was conducted and sponsored by VersionOne in June and July 2008. It received answers from 3061 participants in 80 countries; most of them (70%) were participating to the survey for the first time. The majority of the respondents were agile team leaders, coach or consultants. This could lead to a bias towards a perhaps slightly more optimistic vision of the reality of agile projects. Whether they are agile or not, managers stay managers ;o)

Secretaries Make the Best ScrumMasters

August 29, 2008 by mcottmeyer

Okay everyone. First I want to say that I am happy to be here writing for Agile Software Development. I appreciate Artem reaching out and giving me this opportunity. I really hope you guys enjoy what I've got to say. I promise, I am not short on opinions, and I am never content with the status quo. So… to get started, let's kick this thing off with a question… are you ready?

Do you believe the title of this post?

If you do, don't feel bad, you are not alone. I have been working in project management and around project managers for years. Over that time, I have worked in traditional environments and agile environments. I have worked with PMPs and CSMs. It consistently amazes me the number of people that are converted into project managers for the sole reason they are good at following people around and asking them when they are going to be done.

Best of AgileSoftwareDevelopment.com