My First Agile Project Part 2: Inception & Planning
Originally published on AgileSoftwareDevelopment.com
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.
Inception Phase
The first part of our project was what we called the Inception phase, a sprint or so of basic requirement gathering. Some people call this phase Iteration Zero, a name that I like a lot for nerdy comic-book fan reasons. This phase was good and bad. For me it was good because I was fairly new to the company and I learned a lot about how the business works. For some background, I work at an insurance company and the project is to integrate a new billing system to replace our decade-old custom Oracle form app. Billing in insurance is fairly complicated; both insurance agents and insured companies are involved, there are deductibles, claims, premium charges, etc.
For a month, the senior programmer and I did almost constant meetings with various parties around the company, taking notes and trying to figure out where and how the billing system needed to integrate. This gave us a good list of what integrations we would be writing (talking to the claims system, printing checks, probably a dozen primary integration points overall) and what some of the customizations we would need to do were. What I didn’t like about this process was that we were directed to write integration documents for each integration point, including descriptions of what they did but also flow charts of program flow and a lot of detail we didn’t need. Being new, I did learn from these documents but nothing I wouldn’t learn again, or in some cases have to un-learn, later when we started doing more in-depth requirements gathering. Next time, we’ll do the meetings to get a handle on what integrations we have to do but we’re not going to do all the documentation again.
Since we were doing Scrum, we weren’t supposed to get too much detail in these meetings. “Snorkel”, not “Dive” was the direction given. Eventually though, you do need to dive deep to get enough to work with. A problem we had a lot was that our Subject Matter Expert / Product Owner had a lot to be expert on so she was incredibly busy all the time. We would assign tasks in the sprint planning meeting, then go get deeper on requirements gathering. This meant a lot of the time we were waiting on her and the people she needed to meet with to get enough detail to work with. If you’ve ever had to wrangle the schedules of more than 2 managers/directors in a company, you know how the days can fly by trying to get everybody in the same room.
I’ve since learned that the recommended practice is to make sure your SME starts gathering requirements for the next sprint’s tasks. This would have made things run a lot smoother. Since your backlog should be prioritized ahead of time, the SME should have a good idea of what’s going to get worked on next time even thought it’s the team that decides. With a good base of details in place, work can usually start and intelligent questions asked once the clock is ticking on the sprint.
Sprint Planning
We did 4 week sprints on our project and we had around 10 developers, including 2 database experts for converting our old data. This meant that our sprint planning meetings ended up being all-day affairs. We tried a lot of things to shorten them but never really succeeded. As I mentioned in Part 1, we didn’t estimate difficulty on our backlog items ahead of time (a mistake, in case you missed Part 1). We had our list of integrations and known configuration changes, and it was somewhat prioritized. So in the planning meetings, the first thing we would do is take the top bunch of items and move them one at a time into the Sprint Backlog. As we did that, we would take our best guesses at who would do the work and how long that person thought it would take.
I know some people say you shouldn’t assign work directly to people in your sprint planning, instead assigning it to the team and letting people pick work off the team list. We didn’t feel like this would be the best plan. Even if we hadn’t done specific assignments, tasks would have mostly fallen on the same people anyway due to experience levels, specialties, etc. And when you assign to people, you have a better idea of how full everybody’s plates are. Of course it’s still a team and we all did our best to help out with everybody’s tasks so even though someone’s name was on something we all knew we should take or give tasks as needed. If you have people who don’t take tasks or appreciate the help, that’s probably Job 1 to take care of. Agile is largely about the team and if your team doesn’t work together, it’s a lot harder.
At first we didn’t do very much breaking down of stories into tasks since we were so new to the product and really didn’t know what each tasks would entail. Without a lot of good information about the tasks to go on, our estimates were hit or miss, honestly. Sometimes things that looked easy would run into some snag in the product and take 2 days. Sometimes things we thought might be impossible took 2 hours. (Being able to say “We thought this might be really hard but I got it done in 2 hours” is impressive during a demo, believe me.) Doing estimating on an integration project with an off the shelf product with an architecture of its own that you need to get familiar with is a different beast than green field development. You can know how to do something from scratch and have no idea how to do it so it integrates with somebody else’s product or APIs. It’s worth doing your best to figure it out though. If you start a sprint without a good idea of how much work something might be, you could spend all sprint just getting requirements nailed down.
Next Time
Once you’ve planned and done your tasks for the sprint, you need to show off what you’ve done and get feedback from the people involved. The next couple of posts in this series are going to be about our demos and issues of management buy-in and stakeholder involvement. What we did, the successes and failures we had at demos, and more coming soon. Thanks for reading and I’d love to hear your comments and experiences below.
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.
Inception Phase
The first part of our project was what we called the Inception phase, a sprint or so of basic requirement gathering. Some people call this phase Iteration Zero, a name that I like a lot for nerdy comic-book fan reasons. This phase was good and bad. For me it was good because I was fairly new to the company and I learned a lot about how the business works. For some background, I work at an insurance company and the project is to integrate a new billing system to replace our decade-old custom Oracle form app. Billing in insurance is fairly complicated; both insurance agents and insured companies are involved, there are deductibles, claims, premium charges, etc.
For a month, the senior programmer and I did almost constant meetings with various parties around the company, taking notes and trying to figure out where and how the billing system needed to integrate. This gave us a good list of what integrations we would be writing (talking to the claims system, printing checks, probably a dozen primary integration points overall) and what some of the customizations we would need to do were. What I didn’t like about this process was that we were directed to write integration documents for each integration point, including descriptions of what they did but also flow charts of program flow and a lot of detail we didn’t need. Being new, I did learn from these documents but nothing I wouldn’t learn again, or in some cases have to un-learn, later when we started doing more in-depth requirements gathering. Next time, we’ll do the meetings to get a handle on what integrations we have to do but we’re not going to do all the documentation again.
Since we were doing Scrum, we weren’t supposed to get too much detail in these meetings. “Snorkel”, not “Dive” was the direction given. Eventually though, you do need to dive deep to get enough to work with. A problem we had a lot was that our Subject Matter Expert / Product Owner had a lot to be expert on so she was incredibly busy all the time. We would assign tasks in the sprint planning meeting, then go get deeper on requirements gathering. This meant a lot of the time we were waiting on her and the people she needed to meet with to get enough detail to work with. If you’ve ever had to wrangle the schedules of more than 2 managers/directors in a company, you know how the days can fly by trying to get everybody in the same room.
I’ve since learned that the recommended practice is to make sure your SME starts gathering requirements for the next sprint’s tasks. This would have made things run a lot smoother. Since your backlog should be prioritized ahead of time, the SME should have a good idea of what’s going to get worked on next time even thought it’s the team that decides. With a good base of details in place, work can usually start and intelligent questions asked once the clock is ticking on the sprint.
Sprint Planning
We did 4 week sprints on our project and we had around 10 developers, including 2 database experts for converting our old data. This meant that our sprint planning meetings ended up being all-day affairs. We tried a lot of things to shorten them but never really succeeded. As I mentioned in Part 1, we didn’t estimate difficulty on our backlog items ahead of time (a mistake, in case you missed Part 1). We had our list of integrations and known configuration changes, and it was somewhat prioritized. So in the planning meetings, the first thing we would do is take the top bunch of items and move them one at a time into the Sprint Backlog. As we did that, we would take our best guesses at who would do the work and how long that person thought it would take.
I know some people say you shouldn’t assign work directly to people in your sprint planning, instead assigning it to the team and letting people pick work off the team list. We didn’t feel like this would be the best plan. Even if we hadn’t done specific assignments, tasks would have mostly fallen on the same people anyway due to experience levels, specialties, etc. And when you assign to people, you have a better idea of how full everybody’s plates are. Of course it’s still a team and we all did our best to help out with everybody’s tasks so even though someone’s name was on something we all knew we should take or give tasks as needed. If you have people who don’t take tasks or appreciate the help, that’s probably Job 1 to take care of. Agile is largely about the team and if your team doesn’t work together, it’s a lot harder.
At first we didn’t do very much breaking down of stories into tasks since we were so new to the product and really didn’t know what each tasks would entail. Without a lot of good information about the tasks to go on, our estimates were hit or miss, honestly. Sometimes things that looked easy would run into some snag in the product and take 2 days. Sometimes things we thought might be impossible took 2 hours. (Being able to say “We thought this might be really hard but I got it done in 2 hours” is impressive during a demo, believe me.) Doing estimating on an integration project with an off the shelf product with an architecture of its own that you need to get familiar with is a different beast than green field development. You can know how to do something from scratch and have no idea how to do it so it integrates with somebody else’s product or APIs. It’s worth doing your best to figure it out though. If you start a sprint without a good idea of how much work something might be, you could spend all sprint just getting requirements nailed down.
Next Time
Once you’ve planned and done your tasks for the sprint, you need to show off what you’ve done and get feedback from the people involved. The next couple of posts in this series are going to be about our demos and issues of management buy-in and stakeholder involvement. What we did, the successes and failures we had at demos, and more coming soon. Thanks for reading and I’d love to hear your comments and experiences below.