This post is a continuation of my series on adopting healthy practices that enable an organization to make the agile transformation. You can read the first four parts of this series here:
In Part III (Backlog Management), we talked about how features are placed on a backlog to set the vision for a project prior to starting the first sprint. Now that we know the key players that need to be represented by one or more people as described in the previous post, let’s describe the flow of executing a sprint in detail. Recall from the Backlog Management post that a sprint is a fixed period of time during which the development team works on features before “coming up for air” (review and re-prioritization by the business). Below is a diagram depicting the steps in execution of a typical sprint. I’ll describe each step below the diagram.
1. Analyze market, set vision, scope and/or mockup initial features
During this step, the Customer Champions and/or Competitive Analysts, along with Visionaries and major stakeholders on the project (or maybe one guy in a startup!) collaborate to set the vision for the project. The vision may be “create the best recipe management software on the web”, “solve world hunger”, “solve the problem of sharing documents between manufacturers and suppliers”, or “create a culture for development of web 2.0 products in the pharmaceutical industry”. There are hundreds of business books out there to help you craft mission statements or culture mantras for your business or project so I’ll leave that as an exercise for the reader. At some point however, a critical decision must be made as to what level of analysis will be done prior to involving development at this step. On a very agile project with pressure to aggressively be first to market, it is easy at this step to come up with only a list of features and add these to the backlog as described in Business Backlog Prioritization in the Backlog Management post. Then the highest prioritized features are assigned to developers (as I’ll describe soon in more detail) and they collaborate with the customer representatives to come up with user interface or use case designs.
In my experience however, I find you will actually get to market faster with less refactoring churn if you make a “throwaway mockup” of the entire project/product at this point. The goal here is to select a single developer or designer (the Usability Expert from the Key Players post) and work with the Customer Champions to create mockups for every screen in the system before the first sprint begins. Doing this up front has several benefits. First, it forces the customer representatives to think through all the features they want to build in more detail than the simplified list a backlog provides. This will aid in getting a feel for the total size of the project during planning. Secondly, it gives developers a general roadmap to look at when designing features in a sprint where they can identify patterns earlier to reduce refactoring. For example, lets say that your application has a feature that allows users to attach photos to their profile through a web page. The developers implement this feature in sprint 1 and the business is happy. In sprint 5, the feature “add ingredients” is now designed and it comes to light that photos should also be attached to ingredients. The developers may have implemented the photo attachment feature in a fashion where it is “hardcoded” to only support a profile, and they now need to refactor the code from sprint 1 to handle multiple types of objects to which an image can be attached. Had these photo attachment features been available through a throwaway mockup prior to starting the project, the developers could have analyzed the throwaways to identify the pattern of photo attachments when designing the first sprint’s feature and avoided the refactoring.
The important thing to note if doing a throwaway mockup however is that it is simply that – a throwaway. The final designed screens do not need to have the same style, layout, and even navigation. Think of it as a user interface brainstorming and business analysis scoping tool. It’s purpose is to guide the design of features in a sprint without complete blindness as to opportunities for reuse between features in future sprints, without spending a ton of time doing “real” user interface mockups. In some projects this may not be feasible because the business doesn’t want to spend the time it needs to really scope out everything up front. Another common concern is how to utilize developers while this is going on. I’d suggest they spend their time researching, prototyping, and learning about the technologies that will be used regardless of the features that will be implemented. The time needed to decide on exception handling, data access, security, and other approaches at this point is well spent. A Development Lead can also analyze the throwaway mockup when available to help them make the best technology selections.
Here the Customer Champions shuffle the backlog as described in the Backlog Management post and put the most important features to them on top.
3. Highest Priority Features
Next the Development Lead and Customer Champions agree on the features that will be done next and select a number based on the available developers in the team (I suggest one per developer) and take them off the Product Backlog, adding them to the current Sprint Backlog. At this point, the items in the product backlog are “free” so to speak, and available for the Customer Champions to reprioritize, add to, and remove from while the sprint backlog is being worked on by the development team. I’d suggest managing the sprint backlog in a tool or spreadsheet that can be filled out with the following information about each feature being worked on in the sprint as it progresses:
- Feature name
- Assigned developer
- Status (“Designing, Implementing, Testing, Complete” at a minimum – more if you need to track at a finer granularity)
4. Collaborate to Produce Mockups, Business Rules & Ubiquitous Language AND 5. Assign and Estimate Features
During this step the goal is to have collaboration occur between developers and Customer Champions resulting in agreement on terminology that describes the domain of the problems the software is trying to solve. This happens through discussions, meetings, and online collaboration as necessary. The resulting terminology is the Ubiquitous Language as described in Domain Driven Design.
the Development Lead and other developers meet to assign one feature from the sprint backlog to each developer. At this point, there are two approaches I’ve seen taken when doing the design and each have their positives and negatives.
The first approach to agile design executes step 5 before step 4 and involves each developer taking ownership for the entire process of building that feature from analysis all the way until it is handed off to QA. This requires developers who are very talented, self starters, have solid experience in usability, object oriented design, and an ability to identify opportunities for reuse. Be realistic about your confidence in the equal talents of all of your resources before taking this route. In this approach, each single developer collaborates with the Customer Champions to come up with user interface mockups (in a system with a UI) or system use descriptions (in a service or headless system) for the feature they are responsible for. These collaborations can result in mockups, napkin drawings, use case documents, prototype APIs, eXtreme Programming story cards, or any other method of tracking. It’s important however that no matter what approach is used, the following artifacts of each case are at initially captured as part of the design:
- How does the user (or system) get to this feature – this only has to describe what’s known in this sprint, and not all possible navigation opportunities at this point. Use the throwaway mockup as a guide if you made one. At least think about it!
- What validation is performed when the user (or system) interacts with this feature – Take a crack at this before coding, even if you will (inevitably) uncover more during implementation.
- What are the “default values” that fields or API parameters are set to when the user (or system) interacts with this feature
- What job role (or system role) do the people (or systems) who interact with this feature belong to – Again, take a crack at this up front, it’s many times easier to design for security permissions at the beginning than later.
- What actions that the user (or system) can take when using this feature change the state of other aspects of the feature – For example, “when you select this combo box, it filters this other one” or “if you pass true to this parameter, the data returned is filtered in this way”.
Remember that even though most agile books will tell you that use cases are outdated, much of the same information captured by them is still important to identify at this step when using other methods. If you choose to use another methodology to gather the needed requirements, great – the better job you do of capturing details, the better estimate you will have.
The benefit to this first approach (letting each developer own the entire design process for their assigned features) is that there is a potential for increased productivity if multiple Customer Champions are available. The downside is that developers may not identify opportunities for reuse and learn each other’s subset of the Ubiquitous Language at the same time.
The second approach to agile design executes step 4 before step 5 and involves the best developers on the team being the primary analysts and designers of every feature. This has the benefit of letting the most talented developers shine in creating the user interface and primary models of the software. In most teams, you’ll find a higher quality of code and increased consistency from feature to feature if you go this route. The downside to this approach is that the junior developers not involved in design of the features have to find something else to do. In reality this is rarely an issue unless your developers write 100% bug-free code as they will be fixing bugs from their prior features while the next highest priority features on the backlog are being designed. Businesses can get paranoid about having these junior developers in “feature limbo” during this period, however the pain incurred by having a junior developer take on the design of a feature that is over their head (and in isolation from more senior developers) and resulting in a bad design is enough to eradicate this after a couple occurrences.
You may have read about YAGNI – “don’t build it until you need it” is the mantra here. And while I both love this article and agree with it’s premise completely, don’t mistake YAGNI for something you are going to need, but is just coming in a future sprint. If it’s on the backlog but just not assigned to the current sprint, there’s still a good chance “you’re gonna need it”. If it’s not, don’t spend time at all on it. When in doubt, work with the business to determine the rank of a future feature that may have an impact on your design of the current one – sometimes it may be determined that it’s a “nice to have” feature that is far off in the distance and won’t even be implemented in the current release.
As soon as developers have had initial collaborations with the business and have a scope for the feature, they should update the estimate in the sprint backlog with a rough estimate. In a future post I’ll describe the sprint planning and management process by which a Development Lead or Schedule Facilitator (described in the Backlog Management post) can shift features to future sprints to have things line up more easily. As soon as the developer designing the feature has produced all artifacts other than the code (mockups, story cards, use cases etc.) they should update the estimate with a more detailed (and more accurate) value. This estimate should include the time they think will be needed to write unit tests to the level of coverage agreed upon by the team but not include the time needed for any additional testing by QA personnel. I’ll talk more about agile estimation in a future post.
6. Implement Features
During this step, developers do what they do best – design and write code. The activities that take place here are outside of the scope of this discussion, but an important aspect of managing the sprint is to track the status of each feature as it progresses through being built. As the sprint progresses, developers can update the estimate or provide a “time remaining” on regular intervals, but this is up to your organization to decide. Remember that a big part of the agile process is to eliminate waste. If status is being gathered just to put pressure on developers, you probably don’t have the right people to do agile development in the first place. If you are going to enable agile development at an organization, you should be using professional resources that do not need to be told what to do.
7. Test and Validate Implemented Features
Whenever a feature is done being coded and unit tested by a developer, it’s status should be set to “Testing” and QA personnel should be notified that this feature is ready to test. At this point the developer who implemented the feature should organize a collaboration with QA to communicate what’s been implemented in detail, as there is a good chance that what was designed going into the sprint has had some changes since the beginning. Don’t bother updating the design documents – the tests written here are your documentation for what is currently implemented. Once this feature handoff occurs, that developer picks the next highest item off the product backlog to work on. The goal is for each developer to finish at least one feature per sprint to have something to show at the end, but depending on the length of sprints and complexity of features, there may be several features implemented per developer per sprint.
The QA testing process is very much specific to your technologies and organization. Regardless, developers should be prepared to have to balance fixing bugs found in previously completed features with developing newly assigned ones. This underlines the importance of developers not handing features off to QA until they are really well unit tested and complete.
8. Mark Features as Accepted for Sprint Review
When features have been tested by QA, and no bugs that must be fixed before that feature can be shipped exist, the sprint backlog’s status for that feature should be updated to “Accepted”.
9. Present and Gather Feedback on Tested Features
Near the end of a sprint, developers should coordinate with one another to try to make sure that any new features being worked on do not break the functionality that was already “Accepted” in prior features for that sprint. There will be cases where to move forward existing features must be broken, but if these changes cannot be made in a way that allows the original features to still be presented to the business, that feature’s status should be rolled back from “Accepted” to “Implementing”.
After developers have coordinated their efforts and the last day of the sprint concludes, a meeting should occur in which developers demonstrate the implemented features to the business. At this meeting any changes or enhancements that are requested should be added to the product backlog and prioritized along with whatever else exists at the top of the backlog.
10. Combine Sprint Feedback with Customer Feedback and Market Evaluation
Here is where the agile process really shines. At this point, we should have some shippable features, a list of changes or enhancements (potentially) to those features gathered in the sprint presentation meeting, and an updated evaluation of the market (our competitors and users’ needs). The business can then decide again what’s most important. Has the market or users’ needs changed such that existing planned features are lower priority or no longer necessary? Is there a new market need that is more important? Are changes found during the sprint meeting the most important ones to build next? Whatever the answer, the business is armed now with assets and options for re-aligning the efforts of the development team, perhaps radically if needed, without disruption to the quality of their work or the schedule. When the Customer Representatives arrive at their updated prioritization of the backlog, the process continues again at “scope and/or mockup initial features” from step 1. In future posts I’ll discuss planning, estimation, important traits to look for in the key roles to execute this process smoothly, tools to use, and tips to successful sprint execution.