Articles
How to get the most from (SCRUM, etc.) Agile
Scroll down for more...
NOTE: This article expresses the explicit approach to requirements development recommended by Agile Down-to-Earth - take it or leave it as you wish There is one project phase that is more often identified as a source of eventual project trouble than any other: Requirements development (aka Product Planning). [as you can see - this article focuses on 'project' requirements development, but the principles apply to even small enhancements - Paul] Now this may seem counter-intuitive, since it is Agile that is designed around embracing 'fuzzy' requirements, but that is not a true reading of Agile in most cases. Agile works best in a 'mature' planning organization. The better you plan, the more effective your Sprinting can be. The goal of this phase is to completely understand the product to be delivered (but not to deliver any of it as some are tempted to do). This phase can be very short and still be successful, but often it is when we spend too little time or resources in this phase that problems arise. Agile Requirements Development is focused on discovering and writing the detailed User Stories and other requirements needed to enter the Risk phase of your project (see the 80/20 rule below). The requirements team should be entirely focused on that simple (sounding) result. We need to be sure we know what we want to build (and in what priority!) before we start to build anything. After this phase we can be more accurate with our resource requirements and develop cost estimates for the Sprint (development/build) phase. Lessons learned from other projects have shown that when we do not develop our requirements completely and do not focus sufficiently on User Story development, we set ourselves up for great difficulty later. Use this phase to know a great deal about what you are about to build before you start, and keep it small (hint: keep the entire project release to only six months). Agile Requirements DevelopmentThe goal of the Requirements Development (Product/Release Planning) phase is to capture and record the complete Backlog for the next product release. This starts with vision sessions and modeling sessions that elicit these requirements as high-level User Stories called Epics and Features. These Epics should capture all the high-level requirements of your entire project. Epics should then be broken down into features. Once you feel that you have a good handle on the high-level requirements, you will need to continue the requirements break down to create all the User Stories you expect to include in your next product release, ranked by business value and assessing technical risk. The Requirements Development team These are the most important participants you should be looking for to participate in requirements development... Core Team:
(Hint: use the 80/20 rule) Agile Down-to-Earth guidance asks that all of your User Stories for this product release be at least 80% "complete" before Feasibility is done (AND the Stories for the Sprint phase's first two (2) Sprints are 100% complete). A 'complete' Story has… 1.) All of its acceptance criteria 2.) Been estimated (Story points) by the technical team 3.) Its "technical risk" has been assessed, and 4.) Been prioritized and ranked by the Product Owner Completing the Feasibility phase correctly can take a lot of hard work. That is a good thing, because hard work in this phase prevents wasted work in the Sprint phases. But, consider keeping your release scope small (about 3 to 4 months of development). You must understand the high-level scope of your entire project, but if you try to define the next two years' worth of work in your Requirements Development phase, you will never finish (we recommend that all projects build only what can be completed in Six Month Releases). And remember to assess the technical risk of your stories. When you move to the Sprint phase of this project, you should target the most technically risky as well as the most valuable User Stories , first. Do you have the right team for Requirements Development? In Agile Down-to-Earth, the Requirements Development phase is not a "Sprint" phase. So, there is no development or coding happening now. The team that is working together is trying to build a complete Backlog of work, from which the development team(s) can pull their work. The solution architecture and also the user experience vision must both be designed and approved in this phase. Data sourcing and database design may also be part of this solution, and they must be completed now. New technology choices must be approved and finalized - including negotiating licenses and making plans for purchasing new software before Sprinting can start. Be sure you have the right skills on your team. POCs While it is true that no coding of the actual solution should be done during this phase, it is sometimes necessary to prove a software solution is a good fit, or to ask key questions before Sprinting can begin. A proof of concept (POC) during this phase should be used only when needed, since you may need external resources and funding will likely be limited. Avoid using the POC as a way to code your solution during this phase. That is what the Risk phase is for. How do I know when my Requirements are done? So, it is obvious that if you are going to define completely up to 100% of your entire solution, Requirements Development could go on and on. You want to get as much clarity in this phase as possible, but change is inevitable and too much work now will become a waste, later. So, how do you know when you are done? The key concept in getting to done in this phase is the size of your release. In a waterfall project we would define the entire scope up front. In Agile, we still define and design fully, but we take smaller bites at the apple. Smaller steps allow for significant change without the big downside impact. We want the changes that come up in a Sprint to be relatively minor. It is up to us to make this phase count and try to decrease the likelihood of major changes later. So, being "done" means knowing what the business stakeholders want spelled out as complete Stories, with architectural, UX, database, etc. designs finalized and ready for Sprinting. Six Month Releases Consider planning for only the most valuable Sprint work in your Requirements Development phase. If you are working on requirements that will take more than three or four months to code and deliver, you may be taking on too much all in one phase. Change is constant, and we embrace change by delivering what is most valuable now, and then reevaluating what we are delivering often by keeping releases small. The UX Role Note that the core Feasibility team includes the UX Architect. For most projects this is an essential role. If you are developing anything with a user interface, the UX Architect should be providing the Style, Look and Feel of that interface during the Requirements Development phase of your project. Before Sprinting starts, you will want to be sure to have shared with your teams the style guide, screen mockups, interaction guide, prototypes, or any other artifacts that provide your developers the specifics of how their code must look, feel, and act. Finish by Estimating all your Stories The final step that must be completed before Sprinting begins is estimating the backlog – or at least the backlog that you will be Sprinting on in the build phase. Take the Core Team – especially the Technical Lead, Application Architect, UX Architect, and QA Lead, and do Story Point estimation on each Story. Alternately, make this the first exercise in your Risk phase that you do with your Sprinting teams. Then you will know the exact Story Point estimate that you will deliver in your Risk/Value Sprints. This is essential to scope control and reporting. While you are estimating, also track the Stories that suggest the most technical risk. You will add these to the focus of your Risk phase. Article SummaryAre we sure we should build this, and are we ready to begin building? Those are the questions that must be answered in the Requirements Development phase. Do you know what you are building, what software you are using, what the user should see and what value this project is going to deliver? Have your designs been approved by your key stakeholders? This is not the phase when you should be coding, but it is the phase that primes the pump that will feed your coding engine. No Sprinting is done now. Work is focused on completing the entire scope of the first release of your product (with about 80% precision) - so keep your releases manageable. Try not to look further than six months out. That means no more than three or four months of full-time Sprinting are going to be possible. Failure to complete the majority of your scope definition now leads directly to customer and team dissatisfaction and major scope creep later. Applying Agile means capturing change early, but incremental change is still our goal. Planning for an Agile project is just as important as it was in waterfall; you simply keep the focus on the most valuable things that we can build soonest. Take on too much work and the Scrum machine can break down. Use this phase to clearly identify your most important features, as well as your riskiest User Stories, but keep the scope down, and the development teams will be able to move quickly and effectively through your Backlog with fewer impediments and surprises.
0 Comments
Your comment will be posted after it is approved.
Leave a Reply. |
AuthorPaul Berryman is a passionate application development leader who has earned the title of champion of Agile and DevOps methods and tools for enterprise development teams Archives
September 2014
Categories
All
(c) 2016 - Agile Down-to-Earth All rights reserved |