In the first installment of this Introduction to Agile Project Management series, I wrote about Setting the Scene: why we need to be Agile, Feasibility, Vision, Justification, and Initiation of Agile Projects. In part two of the series, I wrote about The Team, the Project Brief, the Culture and Ways of Working, and Backlogs of an Agile Project. Consider checking out those articles first before reading on in the series. In this installment, I write about Roadmaps and Story Maps, Product Iterations, Adaptive Planning, Story Creation, Sprinting, and Defining Being Done.
Roadmap and Storymaps
A roadmap is exactly as it sounds; it offers the same as a roadmap of a country. It details the relative position of cities (or in your case, features) to each other, and the routes that can be taken to get from city A to city B, or feature X and feature Z. It doesn’t tell you which route you should take, or how you should get there. It doesn’t tell you which mode of transport to use, but it might illustrate options to take the highway or the train.
In a city, there are many roads, buildings, parks, services, and facilities. All features of a city. This is also true of the roadmap for your product. At this level, your roadmap shows major goals or milestones to be achieved. A goal is a logical grouping of themes, features, and User Stories rolled up in a consumable view that demonstrates tangible value. The roadmap of a software product shares this view and communicates your intent. It doesn’t necessarily show you how or when features will be delivered, only the relative value of the goals and features to you and your business.
One great way to demonstrate a roadmap is to generate a story map. This tool indicates customer-valued prioritization. It lays out the backbone, or essential building blocks of your product. The walking skeleton hangs off the backbone and illustrates the features that make it an MVP. All the other features are what add further value and importance to the system. The story map lays features in relative position to each other and is an awesome visual tool.
It’s worth noting that after carrying out a story mapping exercise, your backlog may need to be refined. This will be apparent where stories have been split into multiple stories, identified as redundant, newly created, or a story has a higher or lower priority than previously thought. The story map is another artifact that is continually revisited and revised.
The Initiation phase is typically performed once in the life of your project. However, many of the tools and documents you created will be revisited and revised throughout the project.
Release Planning
“At last,” I hear you cry, “finally some planning.”.Well, you have essentially been planning all through the Feasibility and Initiation stages, we just didn’t call it as such. This is evidence of iterative or adaptive planning – the art of only planning enough to achieve your immediate and most valuable goals. We’ll see later more about adaptive planning, but for now release planning is our focus.
Your release plan may well be determined by external events. Perhaps there is a trade show you want to demonstrate your app at, or your customers will get most benefit using your app on the run up to Christmas. These are timeline events that your goals may be aligned with. You would most likely plan to deliver user stories or features that make the most sense to facilitate these events. If there are no external dates that you need to consider, then you can just go with feature prioritization and delivering earliest what makes most sense and delivers the most value to your customers.
- If you created a story map in Initiation, this will help guide your release plan. Use it to identify your MVP, the minimum feature set that will get your product in the hands of your customers, start earning revenue, get feedback, and acquire more customers.
- The story map will help you carve out future releases too. But keep in mind that as you learn, get feedback, inspect, and adapt, future releases may change. So don’t plan in great detail.
- You may have from two to four releases in a 12 month period. Don’t do less because your first release is your MVP and gets your foot in your door, after which you’ll want to iterate and release more features and fix bugs in a regular cycle. Don’t do more unless you’re performing well and have plenty of Agile techniques and tools in place to manage continuous delivery.
- Each release is a timebox which is broken down into smaller iterations. An iteration is a timebox. The timebox is one of the most important control measures in Agile.
- To size your release:
- Divide your release timebox by 2. This will give you how many iterations you have. So if you have a release of 12 weeks, you get 6 two-week iterations.
- Then, remove two iterations – you’ll reserve one for a “Sprint 0” iteration and another for a “Release Iteration”. This leaves you with four development iterations.
- Work with your team and product owner to fill each iteration with stories, starting from the top of the backlog and working down. When the team thinks they’ve filled an iteration with enough stories they can realistically achieve based on their capacity in the two-week time frame, repeat for the next iteration(s). Use the release plan and story map to guide what goes into each iteration.
- Do not plan the next release yet. You’ll do that as you near the end of the current release.
- Take the user stories from each of your iterations and add up the story sizes. So if your iteration 1 has 25 story points, but iterations 2, 3, and 4 have 10, 45, and 65 points respectively, you will need to refactor. Target an equal number of story points in each iteration. This becomes your anticipated velocity – the amount of valuable “stuff” completed during each iteration.
- The team may not have worked together before. They are almost certainly working on a new problem or product. They will not perform at their best from day one. For this reason, your velocity may be volatile in the first few sprints. However as the team settles down, it should stabilize. Use this data to refactor your release planning which in turn helps you plan your product with a known velocity and confidence.
- If necessary, break stories into smaller chunks and resize.
- Your release plan, especially early in the life of a project and a new team, is only ever a guide. Do not treat it as a commitment or guarantee that all or these exact stories will get delivered as planned. As your team matures, work gets done, and trust and confidence builds, so will the accuracy of your plans.
- Never force your team to “commit” to more than they are comfortable with. Trust their judgement and their expertise.
- Future release planning exercises will be simpler, because you’ll take the release size, multiply the number of iterations by your team’s velocity, and fill the release plan with the stories that add up to velocity x number of iterations.
Consider this as an example. If you go to a restaurant to eat, you wouldn’t go ahead and order all the items on the menu and expect to eat it all in one sitting. You’d never be able to eat it all, you might not be able to afford the cost, you’ll be sick of food, and the restaurant may close whilst you’re eating the fifth of 19 courses! You may not leave a happy customer, the restaurant may not find you to be a great customer, and the experience will be bad all round. More likely, if you love the restaurant, it’ll be because you enjoyed a lovely meal there once. You’ll decide to go back and enjoy a different meal. You’ll tell your friends, you’ll go there often. The moral of the story is:
- Plan your releases in small chunks.
- Consider your capacity.
- Don’t take on more than you can realistically achieve.
- Revisit the plan often to see what you can change and improve.
- Plan, Execute, Inspect, Learn, Adapt – Repeat.
Release planning takes place often in a software project. Each new release requires a release plan. The release plan can also be refactored at any time during a project. Just take care to not overdo it and fall into zombified planning psychosis. At the end of release planning, you’ll want to prepare for the first iteration, which is where we’re happily going next!
Product Iterations
Your team is in place, they’re motivated, you have an engaged business, your initial planning is done – you’re now ready to build your dreams.
We’ve talked earlier about some of the tools, techniques, and concepts that Agile subscribes to. There are many resources already available that do a great job at laying the foundations for delivering an Agile software project. Pick one, keep it vanilla, and grow into your Agile journey. To help shorten the trauma in deciding the right Agile software development methodology to start with, I’d recommend Scrum. And only Scrum. The temptation will be there to use elements of other methodologies. Don’t do it yet. Save that kind of change until you have lived and breathed Scrum for six or twelve months. Then, if you’ve either determined Scrum alone does not work for you or you want to mature as a team, steadily introduce new methods, techniques, or frameworks.
I choose Scrum as the recommended approach for new teams adopting Agile because it has all the basics built in. It’s very popular and has many quality communities and resources online, in books, or in the training room. It will serve you well, even for the smallest of teams. The rest of this post is dedicated to discussing some important aspects of software delivery that you, your team, and stakeholders should always keep in mind.
Adaptive Planning
Planning in an Agile project is an ongoing process. We do some initial planning up front, just enough to understand what we know at a given point. Our initial plans will be loosely defined and flawed. Then we iterate our planning, adapting to new information, planning in greater detail just before we enter into delivery, responding to changing scope. This is one way of minimizing waste – only putting effort into planning when we need to.
- The team and the business, or its informed and authorized representative such as a product manager, actively plan together. The team because they are the experts that will deliver; the product manager because they are the expert who can guide the needs of the business.
- Estimates for user stories will be less accurate the further out they are from being developed. For example, Epics will attract high-level estimates that will be based on a lot of unknowns. Well-defined granular user stories that are estimated just before a sprint starts will be much more accurate.
- There are many estimation “scales” you can use. Use the technique that feels most right for your team and the right stage of planning – wide band delphi,planning poker, ideal time, relative sizing, story points, or t-shirt sizes.
- When sizing a story, one size really does fit all. All stories should be sized using the same technique and encompass all elements such as design, development, testing, and refactoring. When you come to do iteration planning for a sprint, certain tasks can be created which all contribute to the completion of the story.
- Always factor in risk, unknowns, outside influences, your team’s capacity, and ever-improving velocity into your planning.
- If user stories that were taken into a sprint were not completed, we do not extend the timebox. These unfinished or unstarted items are put back to the top of the backlog and taken into the next sprint.
- Always plan to deliver the least amount required to achieve a given goal. Identify techniques to prune features. Reduce waste – find the real value that can be realistically delivered with your time-constrained resources.
Story Creation
Stories get elaborated upon when you need them. You don’t need full story explanations for features that are 6 months away from being delivered. Writing them at the beginning may be wasted effort, when that need disappears from scope. Write your stories at most two iterations before they are needed. Reducing that timeframe to one sprint is preferable.
Let’s take your time in Sprint 0 to set the scene. In two weeks you’ll start development. It’s now time to take enough of the stories from the top of the backlog that could potentially get delivered in Sprint 1. You might take ten or fifteen-percent more if you’re unsure on your velocity. These one-liners can now be expanded into truly valuable documents with scenarios, acceptance criteria, and wireframes. If the wireframes haven’t been created yet, now’s the time to do so. You might find as you review these candidate stories that they need to be broken down. Perhaps they were Epics that couldn’t possibly be completed in a sprint. If you break stories down, re-estimate them with the team.
A good story follows the following rules:
- Written in a common format, e.g. AS A___ I WANT ____ SO THAT ____.
- Includes acceptance criteria that the story must meet to be considered acceptable to the business for sign off.
- Uses language that the business and your customers understand.
- Follows the INVEST model.
- Includes all supporting documents to inform the developer, designer and tester: wireframes, technical design overview, other assets.
- Meets your standard Definition of Done criteria.
Sprinting
Whether you call it a sprint, an iteration, or a timebox, each incremental delivery of your Agile project is time-constrained. The timebox doesn’t shorten and it doesn’t lengthen. Focus on two-week iterations at the beginning. You might find that one, three, or four weeks suits your business model better. Once you choose a length, don’t change it. You want to maintain a regular cadence, or a sustainable pace. This means the team and business focus on delivering regular software without mad-dash overtime being employed to get the job done and releasing potentially shippable increments every two weeks.
- Working in small increments has a huge benefit. It means you’re only focusing on the immediate future of delivery; and with new input, feedback, and learning, you can respond to change within a short iterative cycle.
- At the beginning of a release, perform a Sprint 0. This lets the team, the business, and your project release get geared up and sets the mindset for successful delivery. Draw out the base technical framework and architecture that will support the foundation for the release: setup environments, accounts, and tools. Perform spikes to understand difficult or unknown problems. Elaborate your user stories in readiness for Sprint 1. Sprint 0 is about getting prepared.
- During a release, keep refining the backlog. As you understand more or learn something new, your priorities may change, new requirements may unfold, and what you previously thought was a great feature may get removed entirely.
- Don’t start work that has no chance of being completed within a sprint. If it can’t, break it down into smaller chunks. And don’t start new work when previously started work has not been completed. You create no value by starting lots of things that can’t be considered complete. Further, avoidcontext-switching. This is the activity of starting one task, getting disturbed, and starting another – and at it’s most problematic, not completing either.
- Limit the amount of work that is in progress by the team at any one time. For example, if you have three developers and one tester, you may put a WIP limit on the developers and on the tester.
- Never add more work to a sprint after it has been planned. Never stop a sprint part way through. The exceptions to this are:
- If you performed faster than expected, consider taking the next story from the top of the backlog, as long as it is suitably prepared.
- If the sprint is performing so badly that it will not complete. This usually only happens where there has been a catastrophe of some description.
- If the sprint objective can no longer be supported due to immediate changing needs of the business.
- If you do cancel a sprint, do it gracefully, take time to refocus, and start a new sprint as you would any other.
- Toward the end of a release, consider a final release sprint. No new features are written, some bugs can be cleaned up, and preparations can be made to actually release a new version of your product to your customers. That’s not to say you can’t make incremental customer releases in the meantime – it’s just that this is a controlled, measured, and sustainable release mechanism.
- At the end of a release you might consider a one-week sprint. In this sprint, you might work with the team to breakdown some new ideas or figure out some new technology. These are great activities that benefit the business, and it gives the team some briefing space to think and be creative. It’s not for goofing off, and it will still create value. Equally, everyone needs a break. Taking a vacation at this time helps keep your cadence and velocity in good shape when you’re mid-release.
Defining Done
Defining what “done” really means is very important. There are many versions of “done” within the life of your project – what it means to be “done” with a story, release, or a whole project. It all boils down to what you, your team, and business will consider as complete to the right level of quality to satisfy readiness to ship.
For your team, the definition of a “done” story will be something like all code complete, peer reviewed, meets the defined acceptance criteria, unit tested, UAT’ed, and pushed to your code repository. To enable the passing of a story from designer to developer to tester, will have definitions of “done” to be accepted by the next person in the chain. Your product owner will have expectations as to what this means to them in order to release the product increment to your customers. In any case, everybody must be aware of what “done” means, and be a responsible party in ensuring it’s meaning is met. Define your definition of “done”, communicate it, agree upon it, and evolve it. Done done.
In the final installment of this series, I will write about Continuous Improvement and Beyond the Agile Project.
