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:

Part I: Introduction
Part II: Vision and Risk
Part III: Backlog Management
Part IV: Key Players

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.

AgileSprintPlanning
Agile Sprint Planning and Execution Workflow

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.

2. Reprioritize

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)
  • Estimate

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:

  1. 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!
  2. 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.
  3. What are the “default values” that fields or API parameters are set to when the user (or system) interacts with this feature
  4. 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.
  5. 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.

Category:
agile, process improvement

Join the conversation! 7 Comments

  1. […] Part I: Introduction Part II: Vision and Risk Part III: Backlog Management Part IV: Key Players Part V: Sprint Execution […]

    Reply
  2. […] I: Introduction Part II: Vision and Risk Part III: Backlog Management Part IV: Key Players Part V: Sprint Execution Part VI: Key traits of Customer […]

    Reply
  3. […] I: Introduction Part II: Vision and Risk Part III: Backlog Management Part IV: Key Players Part V: Sprint Execution Part VI: Key traits of Customer Champions Part VII: Key traits of Development […]

    Reply
  4. […] I: Introduction Part II: Vision and Risk Part III: Backlog Management Part IV: Key Players Part V: Sprint Execution Part VI: Key traits of Customer Champions Part VII: Key traits of Development Leads Part VIII: Key […]

    Reply
  5. […] the rhythm and order of development tasks. You can read my previous posts on backlog management and sprint execution to get an overview of how some typical teams I’ve worked with have used it to great […]

    Reply
  6. Sprints are a great philosofy to organizing capsuled tasks into some period of time, but in every period of time there is room for improvements that are missed by those who give up the idea of resource leveling planning, or creating time-sheets/schedules that actually are a result of resources availability.

    I think Agile players are losing an opportunity made by today´s high tech computer and math algorithms that can improve the performance of a team by properly organizing the tasks. And that is happening because a few project managers or developers, or scrum masters, etc have seen adequate scheduling optimization by an advanced project scheduling tool.

    I need a partner to bring up the daily routine of Agile to an improved set of sprint evaluations that will use scheduling techniques to get the job done, even faster.

    While the product owner may choose 5 of 15 items to be executed in one sprint and then other 5 and other 5, thus getting an incremental software with all he needs after a while, what he may not know is that if he chooses 4 in the first sprint and get some other one he did not think is a priority may open an opportunity for in the next Sprint you actually get 7 items done, instead of other 5. That is scheduling optimization as it can be ilustrated with the following 4 tasks:

    Scott will work on Tasks A and B while Peter will work on Task C and D.
    But C and D have a hard dependency on A and B, so we must have A to be performed before working on C and we must have B to be performed before working on D.

    That can happen between items in one Sprint or across the whole project, it does not really matter. What matter is that what seems we cannot improve with scheduling optimization in fact can.

    Imagine that A, C and D will take 10 hours each. B will take 5 hours.

    As of this, by putting A,B, C and D in the same Sprint, they will consume 15 hours of work from Scott and 20 hours of work from Peter.

    If we remember that Peter can only work once A or B are finished, so we have:

    A (Scott, 10 hours) + C (Peter, 10 hours)
    once Scott finishes A, he would work in B (which is parallel to C)

    Next, B will be finished before Peter finishes C and later Peter will need other 10 hours to close the entire deal… From moment one to end, the largest chain of events will take 30 hours.

    If all these tasks are fit to a Sprint with many others, at some point you will finish the Sprint and you may have or not accomplished everything planned to that time period… Imagine that if a bug was found to some of it, the item may have to be removed from the Sprint because there was no time left for fixing it.

    NOW let us take ANOTHER approach and start the Sprint from task B, not A.
    This means that Scott works 5 hours (not 10) and Peter can start working with D.
    While Peter moves to task D, Scott may finish task A with the 10 expected hours in parallel to Peter. Once Peter finishes D, he can work with C as task A has also been completed.

    This new chain of events, with the same 35 hours, the same people and the same hard logic will be executed from moment one to end in 25 hours, not 30 as before.

    THAT IS THE SAME PRINCIPLE in which different machines in a factory will work different tasks, but sometimes by simply changing some priorities, the whole group of activities to be performed fit better in a specific time frame and you have gains in production for the same time period.

    Today´s Critical Path Method principles and the long time spent building schedules in a Gantt Diagram do not make sense with Agile. In Agile, it SEEMS you already know the time as you set the period for the Sprint, so it SEEMS you do not need scheduling techniques.

    HOWEVER, by conducting a good Resource Critical Path planning with the entire group of tasks for an Agile Project, one may find ways of putting more work in each Sprint and therefore returning more funtions to its product master in the same period of time.

    PLEASE, let me expand this example with a Skype talk! My user is petersmello.
    I took the time to write this little article as a comment to your article, let me have a little more of your time so we can get the best of Agile together with the best of Advanced Project Scheduling techniques!

    Regards,

    Peter Mello, Scheduling Specialist, PMP, PMI-SP
    Agile enthusiast.

    Reply
  7. Sorry, as English is not my native language, I did not achieve the desired results with the previous post.

    Here I repeat what I meant, with a more organized structure.

    A Sprint, as a container event with fixed duration, is a great concept to organizing capsuled events into some pre-established period. However, in every period, there is room for improvements that is given away by those who do not see the value of resource leveling planning (or creating time-sheets/schedules that actually are a result of resources availability).

    I think Agile players are losing an opportunity made by today´s high tech computer and math algorithms that can improve the performance of a team by properly organizing the events. That is happening because a few project managers or developers, or scrum masters, etc. have seen adequate scheduling optimization at work generated by an advanced project scheduling tool.

    The daily routine of Agile should open space to an improved set of events in any Sprint that uses scheduling techniques to get the job done, even faster.
    When you establish the period of a Sprint and determines the maximum time of each event, the number of events is greatly dependent of the available resources and usually with a basic mathematical analysis, a Scrum team determines what part of the Product Backlog will fit each Sprint.

    Once said that, one may think that TIME and SCOPE is under control and maximum capacity of product development is what determines the outcome for each Sprint. Later, while Sprints progress, bugs and other non-forecasted events (such as changes in story priorities, quantities and needs) will struggle to survive within the same time containers that determine the overall plan for the product delivery.
    While in “normal” software development, time is the calculated result of the individual needs of each and all events, in Scrum the scope of each Sprint is the calculated result of what can be fit on every capsuled period.

    If all periods would be performed as planned by a “normal” software team and all sets of events would be performed as planned by a Scrum software team the total accomplished work in the total established time could be the same.

    What most differentiate Scrum or other agile approaches to non-agile approaches is that the organization of sets of events, the participation of the customer, the interaction in every iteration that is built and other steps of its philosophy keep the work, the minds, and the people together with a clear picture of what to be achieved. In other words, it is not the Sprint itself that does the trick but the existence of organized control points that helps the team to engage in corrective actions at the very moment problems start.

    Time can be lost by team players even in a timed-box called Sprint, in case that its events are not properly planned and sequenced.

    If a set of stories in a non-Agile approach is conducted with such loss of time, the milestone for the product delivery is disrupted and the project is delivered later.

    If the same set of stories in an Agile approach is conducted with such loss of time, the milestone of the product delivery is sustained, but some events are left for later Sprints.

    – In one approach, time fluctuates and scope is maintained.
    – In another approach, scope fluctuates and time is maintained.

    Scheduling techniques that may support one approach to reduce time fluctuation to its scope can also be used to support the Agile approach to help sustaining the original planned scope to each Sprint.

    In other others, scheduling optimization can help fitting more events in each Sprint and refine the overall distribution of the Product Backlog.

    Let us see four tasks or events that once conducted in a different manner may help the team having “extra time” to work in the same Sprint.

    1. Schwaber will work on Tasks A and B while Sutherland will work on Task C and D.
    2. C and D have a hard dependency on A and B, so we must have A to be performed before working on C and we must have B to be performed before working on D.
    3. Imagine that A, C and D will take 16 hours each. B will take 8 hours.
    4. As of this, by putting A, B, C and D in the same Sprint, they will consume 24 hours of work from Schwaber and 32 hours of work from Sutherland.
    5. Let us assume that the Sprint will last 10 days.
    6. If we remember that Sutherland can only work once A or B are finished, so we have for scenario one:

    • If Schwaber starts from (A), Sutherland will have to wait 16 hours before having its first task (C), which will consume other 16 hours from him.
    • While Sutherland is working on (C), Schwaber will finish (B).
    • Once Sutherland finishes (C), he will move to (D) and that will take him another 16 hours.
    • Assuming 8 hours per day, (A)(B)(C)(D) are finished in a total of 6 days.
    • Schwaber and Sutherland will have other 4 days to perform the rest of the events planned for the Sprint.

    7. For scenario two, we have:

    • If Schwaber starts from (B), Sutherland will have to wait 8 hours before having its first task (D), which will consume other 16 hours from him.
    • While Sutherland is working on (D), Schwaber will finish (A).
    • Once Sutherland finishes (D), he will move to (C) and that will take him another 16 hours.
    • Assuming 8 hours per day, (C)(D)(A)(B) are finished in a total of 5 days.
    • Schwaber and Sutherland will have other 5 days to perform the rest of the events planned for the Sprint, saving ONE DAY to perform other activities or fitting more stories into the Sprint.

    THAT IS THE SAME PRINCIPLE in which different machines in a factory will work different tasks, but sometimes by simply changing some priorities, the whole group of activities to be performed fit better in a specific time frame and you have gains in production for that period.

    Today´s Critical Path Method principles and the long time spent building schedules in a Gantt Diagram do not make sense with Agile. In Agile, it SEEMS you already know the time as you set the period for the Sprint, so it SEEMS you do not need scheduling techniques.

    HOWEVER, by conducting a good Resource Critical Path planning with the entire group of tasks for an Agile Project, one may find ways of putting more work in each Sprint and therefore returning more functions or stories to its product master in the same time-framed-box.

    PLEASE, let me expand this example with a Skype talk! My user is petersmello.

    I took the time to write this little article as a comment to your article, let me have a little more of your time so we can get the best of Agile together with the best of Advanced Project Scheduling techniques!

    Regards,
    Peter Mello, Scheduling Specialist, PMP, PMI-SP
    Agile enthusiast.

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: