Why testing tasks should be part of the task board when you don't have experienced testers

Many Scrum teams feel there's something not quite right about testing and their use of a task board. In this blog post I'll go in-depth on the issue of having testing-related tasks or not on the task board. I have found that this is a typical question especially in beginner Scrum teams.

Example Scrum team scenario

To keep this blog post relatively short I will focus on the following scenario:

1. Automated testing code coverage is medium to low so there is an extra need for manual testing.
2. The product is relatively complicated with lots of intricate scenarios/settings to test.
3. The product is a SaaS with thousands of users.
4. You do not have dedicated testers but you have plenty of access to people outside the team that can help to carry out testing. 
5. Testers are not experienced in testing. They know the product to be tested but are not super users. They prefer not to use developer oriented testing tools because they are not highly technical persons. 
6. Testers outside the team come and go and they are quite busy so they need a simple way to carry out the tests without having to log in to a complicated testing suite. Because of the turnover you do not want to provide a lot of training for testers. 
7. You do not have a test manager, QA lead etc.
8. Developers are also inexperienced testers and have limited knowledge about QA.
9. Developers are writing the test scripts because the testers are not qualified to write high quality test cases. 

This scenario may describe a team with a medium Agile maturity level so other more fundamental actions could also be needed such as QA coaching, adding QA related metrics etc. but we will focus on the question of testing tasks on the board.

What is testing anyway?

You should never rollout a feature/User Story/Product Backlog Item (PBI) without testing. Someone has to test it. This might take the form of unit testing, acceptance testing, security/penetration testing, exploratory testing, regression testing, performance testing, load testing, code review, integration testing, web tests e.g. Selenium. In addition to local testing during development. Maybe you want to add UX user testing and maybe you even need to do some regulatory testing.

The purpose of the task board

Before we discuss if testing tasks should be on the board we should first do a recap of what a task board is for. The task board, as the name implies, is for tasks. The purpose of the task board is to keep track of tasks and create visibility to the team and other stakeholders. This helps the team make sure the right things are completed at the right time [4]. The three pillars of the Empirical process which Scrum and Agile is based upon is Visibility, Inspection and Adaption. Tasks on the task board enables visibility and transparency.

Now, some teams try to cram more information onto the board by adding lanes for server environments or lanes such as "Ready for testing", "In testing", "Ready for staging" etc.
The starter task board with the 3 lanes: "To do", "In progress/WIP/Doing" and "Done" is still the recommended basic setup [1],[2],[3],[4],[5],[6],[9]. Remember that the task board is primarily for tracking tasks.

A task can be in progress, done etc. To say a task is in QA/staging or in testing does not make sense. A user story/feature can be in testing but a task is a piece of work to be done. You don't test a testing task. This inconsistency lies at the root of disagreements on how to visualize testing on the board.

Why not have explicit testing tasks on the board

Typical arguments for not having testing tasks for each story:

• It's extra work to add test-related tasks to each user story. Each user story will often have the same duplicated testing tasks. Seems like unnecessary extra work to add them for each story. 
• Testing is an integral part of development so we don't need tasks for it. It is part of the programming work.  
• More tasks means there will be more overhead needed to pass all the tasks through the lanes of the task board.
• The board gets messy when we add tasks that are to be partially carried out by others not in the core team. We like to have full control of what all the tasks are and not have things that relate to other persons in there.
• Testing is something that is done after we have deployed to the QA servers. Seems out of place and not logical to have them on the board. Testing is sort of another phase of the process and it seems illogical to have it alongside programming tasks. 

Some of these arguments include faulty assumptions.

• "The board gets messy when we add tasks that are to be carried out by others not in the core team". This claim assumes that the team don't need to do anything related to testing. Someone has to write the test cases, make sure the test environment is testable, someone has to coordinate testing, make sure testing gets done, provide support for testers etc. There are also tests that only developers can do like performance testing.
• "Testing is sort of another phase". According to Agile practices this is just wrong [7],[8],[10],[11]. This thinking leads some teams to add a testing lane to their board which again strengthens a view that testing is a phase in the sprint and so test-related tasks are not needed on the board.
  

  

  Example task board with lane for testing

  This can also have the effect that epics are not broken down into small enough user stories and tasks. Since it does not always make sense to have a task in testing you may end up having tasks that are actually user stories. When a task on the board is actually a user story it makes sense to have the "task" In testing. 

Testing is not a phase, but a way of life
   - Elisabeth Hendrickson

Ideally testing should be a collaborative effort between developers and testers going on in parallel [8],[10],[13],[14]. In our scenario this is difficult since there are no skilled testers so developers have to step up and write test cases, provide testing support and coordinate testing [11].

In Scrum and Agile development we strive to complete one by one user story. Testing is of course part of that. One by one story is completed to reduce risk and to be able to deliver value increments.

Alternatives to testing tasks on the task board

Based on our scenario I have identified a few alternatives to having testing tasks.
  

Alternative	Implication for test script writing	Implication on carrying out the tests
Developers write test specifications at the start of the sprint based on the requirements specifications, dev tasks, DOD and Acceptance Criteria.	You don't yet have a working feature so you will not be able to try it out and come up with all the test cases at the start. There will be changes underway so the test script will be outdated. To avoid rewriting the test cases or have to come back to it at a later time the developer will delay writing the test cases. Eventually the developer may forget to do it.	Poor test coverage and outdated test cases that cannot be carried out. Rush at the end of the sprint to get the test script together.
Developers update the test specification continuously as they go along.	Will be forgotten because the developer is in a coding mode and the team does not yet have a high quality focus.	The developer may forget to do testing tasks such as performance tests, integration tests, code reviews, security/penetration tests etc. Rush at the end of the sprint to get the test script together.
Developers write the tests when all dev tasks of a story are done.	Who is responsible? Several developers have worked on the user story. It is not clear who should write the test cases so it doesn't get done.	Rush at the end of the sprint to get the test script together.
Developers write test cases for each dev task.	Many tasks are not testable [12]. Often there are no relevant manual test cases to write and there are different types of testing needed of different tasks and so the developer would constantly need to think about testing. Not all developers care that much about quality. Also the test script needs to be organized into a readable non-overlapping set of test cases. You may not end up with a complete and easy to use test script just from piecing together tests from the individual dev tasks. There is no reminder or test task to check off as completed so the developer may forget about it or defer writing the test cases.	Missing test cases. Tests that are hard to understand. Overlapping tests. Rush at the end of the sprint to get the test script together. If you have a lane for testing this does not mean that tests will automatically be carried out. Because some tasks are testable and others not you don't get into a systematic process of writing test cases and eventually things are forgotten or delayed. Also there might not be a clear mapping between the dev task and its test cases so others will not know if the test cases are written or not.
Developers write the tests at day x into the sprint.	The developer will always want to complete as much features as possible to look good or because he don't like writing test specs. Quality is jeopardized because the developer rush to complete the test specification in order to be able to complete the testing before the sprint ends. This is not Agile.	Testing is postponed, it gets chunked up towards the end of the sprint. You may not be able to complete any stories at all because testing was halted for some reason. The feedback cycle lags behind so critical bugs found during testing could not be fixed in time before the sprint ended or the team have to work overtime, again.
Developers test by trying to break each other's code and find bugs.	In this case there is less need to write a test script. Although this may sound fun to developers this alternative ultimately depend on the QA maturity of the developers and the process. If developers are poor in testing they will find fewer bugs.	Without specific tasks with a timeslot developers may do a sloppy testing job especially if there are no guidelines from managers on expected quality levels or if there are no other incentives for finding bugs.

Some readers might have noticed how central the test script has become in our scenario. Maybe you would like to suggest dropping test scripts all together and just end the discussion right here. Developers should be end to end developers and have the skills needed to test everything along the way as until the story is done [14]. In our scenario with a complicated product this is simply not an option because a test script is absolutely needed for QA to make sure edge cases are both identified and tested. Without a test script you get into a testing procrastination situation. You don't know where to even start testing and what has been tested. Systematic testing is needed in our scenario.

Typical problems in immature Scrum teams when not having testing tasks for each story

Developers usually don't like to do or prepare testing other than technical unit testing and performance tests so you may end up with poor tests and test scripts being ready too late. Developers love to code and develop stuff and often find test-related work boring.

Typically the team will end up postponing testing as a bulk job to be done towards the end of the sprint [7]. As you don't have explicit tasks for writing test specs and the task of writing them is usually seen as boring work for developers they will tend to focus on development and postpone writing test scripts as long as they can. This means that they will usually start to work on another story before the first one has gone through testing. You are now in a situation where developers try to have all stories ready to be tested some time before the sprint ends so testers can take over and begin their work. This is what we would call mini-waterfall (not Agile).

Another problem is responsibility. Who is responsible for writing the manual test scripts, the acceptance tests etc? Who is responsible for coordinating or doing the actual testing. If there's no assigned person you can bet it will be deferred or not done at all when the QA maturity level is low amongst developers.

Another side-effect of not having testing tasks on the board is that some person will voluntarily or not take the role of writing the test specifications because that person know it is the only way it will be done. This person might be good at it and he might even like to do it. The problem here is that it creates a dependency. What happens if this person goes away on vacation or is busy doing other stuff for a period of time? The testing grinds to a halt or you have a severe drop in test coverage.

Why have testing tasks as part of the task board

Example of Scrum board with testing tasks

Better estimates

Time will go into writing test specs, so estimates for it should be registered somewhere. Time will be spent setting up the test environment, doing initial integration tests, regression tests etc. Time will go into fixing the bugs found during testing.

By using test-related tasks you can during Sprint planning have a more conscious discussion around what kind of testing is needed, how much time will be needed and how much extra time should be added for fixing bugs found during testing). With explicit testing tasks you will be able to plan better and come up with better estimates. 

Increased Quality

Sometimes tests can only be done by developers. E.g. performance testing or testing that require specific tools e.g. testing infrastructure related stuff. By defining these tests as explicit you don't forget to do them and you have accountability. Everyone sees who is responsible and if it has been done or not.

If you add test-related tasks during sprint planning you will have a slot to think about testing. You will be able to kick-off some thoughts about what needs to be tested, how thoroughly etc.

If there's no defined task for writing the test script you might be pressured to hurry the job of writing the test cases because the burn-down chart will look bad if you spend too much time writing it. When there are no testing-related tasks on the board there are no estimates to burn. The developer might feel he look less productive than other developers who are working on defined dev tasks so the developer may want to just get the test cases done as quick as possible. Not thought through test cases = poor testing.

If you have testing-related tasks on the board you will be reminded if there are some other types of testing missing.

Who is responsible for updating the test scripts when a bug is found and there was no test to cover it? Without a person in charge of overseeing the testing of a user story this may very well be forgotten.

Reporting and status visibility

If you don't have a task for testing the user story you can't display the status of the testing work on the board. There is no way to see if the testing has started and how many hours remain etc. Testing-related work as any other task can have impediments. If you have test-related work on the board it's easier to have discussions about status and impediments.

Efficiency

In our scenario someone in the team has to coordinate or connect developers with testers. Testers will have questions for how to carry out some test task. There are usually questions such as; is it a bug or is it a known issue? A developer has to be available to answer questions such as why a test task is not testable. The correct conditions, for example the right data might not be present to be able to carry out the test. Without a explicit task for the responsibility of coordinating and supporting the testers the tests might very well stop without anyone knowing. You might have unclear communication lines and get extra noise in the team because people don't know who is responsible for overseeing the testing.

Avoid duplicated work. If the developers test each other work it is still useful to have testing tasks so you know which developer is testing who's work.

Continuous improvement

Reducing waste is central to the Agile movement. If everything is visible you get a better overview of everything going on and how things depend on other things. With testing tasks you can more easily improve the entire process.

Without tasks and responsibilities you don't have accountability. If the test script is bad and there are bugs because of poor tests we know who wrote the test spec and we can improve the process by talking to the responsible persons.

References

[1] http://www.clemensreijnen.nl/post/2012/05/24/09-Getting-Testing-Done-in-the-Sprint-e28093-Test-Tasks-on-the-Board.aspx
[2] http://www.mountaingoatsoftware.com/agile/scrum/task-boards
[3] https://msdn.microsoft.com/en-us/library/jj161049.aspx
[4] http://leankit.com/project-management/task-boards/

[5] http://blogs.atlassian.com/2012/08/greenhopper-bonfire-agile-development-testing-awesomeness/

[6] http://manifesto.co.uk/agile-concepts-scrum-task-board/

[7] http://www.ambysoft.com/essays/agileTesting.html
[8] https://www.youtube.com/watch?v=bqrOnIECCSg
[9] http://www.slideshare.net/mikedep01/building-scrum-boards-that-radiate-information-generic
[10] http://smartbear.com/all-resources/articles/what-is-agile-testing/
[11] https://www.atlassian.com/software-testing
[12] http://programmers.stackexchange.com/a/113837
[13] http://www.scaledagileframework.com/developers-and-testers/
[14] https://www.youtube.com/watch?v=yRP29wFqu20

Why fixed length sprints are important in Scrum

Have you been on a scrum team that sometimes change the length of a sprint or postpones a sprint? You are not alone, and in this blog post I list reasons why doing this is a bad idea. 

Oh, and in case you wondered; fixed sprint length IS a well-documented best practice of Scrum [1, 2, 3, 4, 7, 8, 9, 10].

Sprints best have consistent durations.... A new Sprint starts immediately after the conclusion of the previous Sprint [1].

Some common reasons why a team would want to alter the sprint cadence now and then:

• Vacations.
• Important deadlines/releases.
• Unforeseen issues taking up a lot of time of the sprint.
• Now able to complete important user-stories to be released. 
• Staff unavailable (sick team members etc.) 

Here is the full list of why you should stick to a fixed length sprints (fixed cadence):

1. Improve coordination with the rest of the organization 

It will be easier for everyone to know what kind of Sprint phase the team is in (e.g. planning, development, testing, reviewing). This predictability allows for better coordination and planning throughout the organization. The entire organization can self-organize around this rhythm. 

It also helps you to steer expectations. With a fixed length sprint everyone (PO, management, customers, users, and other stakeholders) will know when they can expect new updates. They will know that a new updates typically comes every 3 weeks (or whatever your sprint length is).

2. Save time planning and booking meetings

With a fixed sprint length you can schedule and make plans more easily. A sprint is always the same length, that's it. Now you can schedule Scrum events for the next year ahead and you can do it in one go. You will have less overhead in planning because you don't have to negotiate what should be the sprint length each time, you don't have to make complicated man-days calculations and you don't have to change all future sprints because you changed the length of the current sprint.

Since you can schedule meetings in advance, people can plan their appointments around the Sprint events, rather than sprints being tweaked to fit the calendar of key team members or stakeholders. 

3. Better quality

In general a fixed-length sprint will remove variability and this will lead to more predictability, stability, better flow, better and more sustainable work environment, less chaos. This of course leads to higher quality. 

If you allow sprints to be shortened, say for example because the top management really want to have the next release earlier you not only loose rhythm but you will either have to work overtime, reduce quality, add more resources, or scope down the current sprint. If you scope down you waste resources and throw away planning/analysis that is already done and other work that has been started. If you decide not to scope down you are typically left with one option on such a short notice. You end up reducing quality for example by pressuring the testing to complete faster or by not letting developers do refactoring and other chores. If you decide to work overtime you still jeopardize quality since tired or pressured team members make more mistakes. 

4. More effective work with better flow

With fixed length sprints it is much easier to get into a flow of doing all the Scrum related events such as backlog grooming, retrospectives, sprint reviews. With a predictable schedule you don't have to think about these events. When is the next meeting, will there even be one?

Without this fixed start and stop you may be tempted to move the start and stop date. You might even delay starting the next sprint long after the previous one ended. Beginner Scrum teams in this situation might not schedule the sprints for the months ahead but instead just start a new sprint when it makes sense. Before you know it you skip a retrospective and have to do sprint planning in the middle of a sprint. All this leads to more unpredictability, questions, chaos and less flow which eventually results in lower performance of the team.

5. Improve estimates

Empiricism [10]. If the sprint length varies from sprint to sprint, then the amount of work accomplished in each sprint tells you next to nothing about what to expect in future sprints. If you know there are many vacation days coming up in the next sprint you are better off continuing with the regular sprint length/cadence, be it with fewer actual work days and just disregard the burndown or dev velocity of that sprint.  

6. Enable continuous improvement 

Sprints can more easily be compared. In Scrum we try to fix as many parameters as possible; Time, Quality, Resources are fixed but we change the work from sprint to sprint. By reducing the complexity down to just one adjustable parameter (backlog items) it will be easier to have discussions around opportunities for improving the process. The more variables you change the more complex the dynamics of the process will be and it will be much more difficult to compare sprints to improve the process. If you change multiple parameters around each sprint, how are you going to know for sure what actually contributed to things going better or worse?

7. Improve ability to predict when future features will be released

The organization or customer will know how long it will take to get new releases out the door if suddenly a new feature absolutely has to be introduced as soon as possible. E.g. If the team is in the middle of a sprint and the sprint length is 3 weeks it will take about 5 weeks to see the newly requested feature in production. If the sprint length is variable it would be far less obvious when you could expect the new feature.

For products planned several sprints down the road it would be even more unpredictable without a fixed length iteration.

Velocity (the rate at which a team delivers stories from the product backlog) is useful in forecasting when capabilities can be deployed and available to end users. Without fixed-length sprints, any measure of “work accomplished” is useless in forecasting. Alternatively you will have to make adjustments in the calculations of velocity based on the sprint length. These sorts of calculations become a waste of time as they are hard to get exact and just add extra work to the Scrum master. You can never hope to be 100% precise on task estimates so Velocity will never be exact science anyway. By having fixed length sprints you reduce one source or error in calculating velocity. Keep it simple, stay lean and pragmatic. Aim for predictability and simplicity and forecasting will be easier and less time consuming.

Sure there will always be holidays, sick days, etc. If a sprint has less resources you simply commit to less [5]. You calculate how many man hours is available and plan the scope accordingly. You may now say that this will affect velocity and number of storypoints delivered for these sprints will be lower. Yes and that is fine because you know the reason why. In the Velocity-over-time-graph you can just make a small note about vacation etc. when velocity had a dip. If you know most of the sprint is going to be all messed up because too many people are away you can also decide for the team to do something completely different. You could let developers take the sprint off doing courses, prototypes etc.

8. Improve team motivation

Fixed length sprint helps the team to deliver continuously and provides a sense of accomplishment at the end of every sprint. The team also commit to a chunk of work at the start of the sprint. The team gets motivated to deliver as they themselves committed to doing the work.

With fixed length sprints you have predictability and the team feels more at ease. People like to have routines and familiarity [5]. Fixed length sprints contribute to discipline, habits and traditions that creates team identity. "This is our team and this is how we do it." This again strengthens cohesion and team spirit, which is important for highly effective teams.

If Scrum events falls on random days of the week every sprint then it is hard to build good habits.

9. Accountability

Fixed length sprints with reviews at the end of the sprint encourages the team to deliver on the sprint review. Without a fixed sprint calendar the chance of skipping reviews gets much bigger. Without this regular review delivery the team may procrastinate, get caught up in coding what is fun rather than sticking to the plan or get distracted by other things. Developers don't want to look bad so they will deliver when it is demo time.

10. Better planning of backlog and roadmap

PO can better prioritize and split user stories now that meaningful data on velocity can be accumulated from sprint to sprint. PO can use this velocity as a guide to plan upcoming sprints.

11. Essential for multi team synchronization and alignment

When you scale to multiple dev teams doing Scrum (co-located or not) contributing to the same solution or product, it is obvious that synchronizing the teams will be more effective [6].

If the different teams operate with different Sprint lengths it goes without saying that the teams will not be in sync.

Conclusion

Scrum is all about delivering software in regular intervals to enable fast feedback and to get a effective cadence for the team. Variable Sprint lengths may seem like a good idea, especially in the short term, but in the long run it will be devastating to the progress of a team. There will always be sprints with  holidays and sickness but the show must go on. Do not postpone sprints or adjust the length of the sprint, just keep moving and avoid unnecessary chaos by accepting that some sprints will have lower velocity.  

If you liked this blog post, you may also want to read Scrum Best Practices: Choosing the Right Sprint Length.

References

[1] http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-US.pdf
[2] http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

[3] http://www.agilitysw.com/blog/31-scrum-whys-fixed-length-sprints
[4] http://books.google.no/books?id=3vGEcOfCkdwC (page 67)  

[5] http://whitewaterprojects.com/2010/12/07/2-models-to-address-the-holiday-sprints/

[6] http://scaledagileframework.com/sprint-execution/
[7] http://www.agileadvice.com/2013/05/15/referenceinformation/the-rules-of-scrum-every-sprint-is-the-same-length
[8] http://blogs.telerik.com/agile-blog/posts/13-09-11/the-importance-of-timeboxing-and-iterations-for-agile-planning
[9] https://www.scrumalliance.org/community/articles/2012/january/a-sprint-is-not-a-mini-waterfall

[10] https://artisanagility.com/never-extend-a-sprint/ 

The best way to conduct a retrospective meeting

Retrospective meetings on SCRUM IT development projects are held at the end of the sprint (usually at 2, 3 or 4 week intervals). The purpose of this meeting is to collectively find out how the team can become better and more effective.

If you are not doing SCRUM development projects you can still use this meeting style. It is all about learning and continuous improvements so this should be relevant for any team (3-8 persons) that is working together over a long period of time, in any type of organization.

Over the years I have been on many development projects and tried different approaches to the retrospective meeting. The following format and structure seem to work very well.

Duration 

2 hours. Usually you will see others saying 1 hour is enough. I think 1 hour can be a bit too short (if you are more than 4 persons) because then you don't really get the time to discuss and "analyze" issues.

Roles

You will need one facilitator (In SCRUM this will be the Scrum master). The facilitator can simply be one of the team members.

Who should attend?

The core team including designers and testers. Scrum master/project lead and product owner.

Preparations

In your daily work keep a notebook at your desk. Immediately when you recognize a possible issue or idea suitable for the retrospective then write it down. Keep one page in your notebook dedicated to notes for the next retrospective. This way you avoid going to the retrospective meeting with a blank head. Even though the meeting is held every 2, 3 or 4 weeks it can be hard to remember things that happened during the sprint.  

The meeting

Timeline

The facilitator initiates the meeting and draws a timeline on a whiteboard. Indicate on the timeline the start date and end date of the sprint. Also put in the half sprint date on the middle of the timeline so it is easier to position post-it notes later.

Each participant then writes down events that happened during the sprint. This should be limited to events that affected the team in some way. Each participant will sit around a table and try to come up with notes without looking on the notes of the others. Write with big letters so it is easy to read when it is put up on the whiteboard.

Events should be relevant. Negative events that seem to be reoccurring should get extra attention. Other private stuff can often be left out. If for example you moved to a new apartment and had to take a day off and where distracted during the sprint, this will affect the team but there's no need to mention it here because there's probably nothing you or the team could do about it, and there's nothing the team can learn from it.

Take turns and put up a post-it note for each (positive and negative) event. No need to discuss each post-it note here. Just be objective and concise. The post-its will make the next step much easier.

What went well and what went not so well

Now start a new round where each participant tries to come up with notes for things that did not go as smooth as it could. On a separate wall or area of the whiteboard take turn and present your note.

The events in the previous step will help you remember things that did not go as well as it could. Each participant presents their note and how they experienced it. Do not make suggestions for solutions at this point and above all do not blame others.

Remember that others may have experienced it totally different. The important point to make here is that all team members get to discuss and share their perspective. Typically you'll discuss it as a problem and what this problem leads to. How severe is the problem? Maybe you are the only one seeing the problem. In that case maybe you need to change your perception of the issue.  

Another important point to make here is that talking about things that did not work out very well can be difficult. It can even become uncomfortable or stressful. Now it's important that you act as a team and help each other. Be honest. We all have strengths and weaknesses. Also, think in systems. When someone messes up, it is usually the system that allows or encourages him or her to do so. Find the underlying causes. Here the 5 whys technique can help to find the root cause of the problem. When a person does something he shouldn't then recognize that there is a weakness in the system. If someone made it happen, it might happen again. Change the system, not the person.

Now take another round of post-it writing. This time it will be more positive and uplifting. Write down what went well. Here you can take the opportunity to pat your team members on the shoulder. If they took initiative to improve something but did not succeed you can still make a note on the effort. You an also brag about what you yourself did that you think worked out particularly well. Usually there's not much to discuss here but it is still important. Most people thrive when they get positive recognition from their peers.

Looking back to the previous retrospective meeting

The facilitator now put up the post-it's from the last retrospective on what to start doing, stop doing, and continue doing. In the previous meeting you made some suggestions for change. Now you can evaluate the changes that have been made since last time. Did you see any improvements? Has anything been done at all about the things you identified in the previous round? Sometimes people agree to make changes, but when you meet up at the next retrospective, nothing has changed. In this case you may want to evaluate your incentive systems. Boring tasks are often postponed when the reward seem low, intangible or distant.

Suggest changes

The facilitator draws 3 columns and adds post-it's from the last meeting. Based on what changes were made this sprint you can now suggest adjustments by coming up with ideas for what to start doing or stop doing. Combine this with solutions for the newly identified problems (what did not go so well). Each participant makes another round with post-it's:

• Stop doing
• Continue doing
• Start doing

This again is discussed in the group. If there is a consensus on a topic the post it will be transferred to the next retrospective. In many cases the stop, continue and start doing thing will be a bit vague. In that case you will need to make more concrete action points. Some of the items will be for the whole team or some of the team members to do. Other items may be for the organization to carry out. In the latter case it will be the responsibility of the scrummaster/project lead to see that it is actually carried out.

Prioritize action points and follow up on them. Put them in your product backlog, to-do list, task tracking system, podio, basecamp or whatever you are using. The items may even be new innovative ideas to register in your idea management system. I happen to work for a company that is developing idea management software. Visit our website inductsoftware.com for idea management software to improve your organization's innovation capacity.

Learn more about retrospective meetings at the Agile Retrospective Resource Wiki.

Requirements reminder

In smaller dev teams in some organizations, small projects often start without much consideration to requirements other than some design sketches. This is a starting point that can lead to several issues down the line, and it is typical when there are no solution architects involved. Once the team (or single developer) has chosen a technical path it might be very expensive to redo the system. The longer the system has been in use by end users the harder it is to rearchitect it.

In this blog post I list typical areas of IT systems. The purpose of this list is to trigger deliberation that can help you formulate a simple requirements specification. 

• Access (Who should have access)
• Accessibility, WAI
• Accuracy
• Adaptability
• Audit and control
• Availability (Service level agreement, downtime)
• Backup
• Branding
• Browser support, clients
• Capacity
• Certification
• Compatibility
• Compliance
• Completeness
• Configuration management
• Configure-ability (can it be reconfigured)
• Correctness (no bugs)
• Cultural and political
• Currency (data is up to date)
• Data structures
• Dependency on other parties
• Dependability
• Deployment (deployment procedures, life cycle turn around and velocity)
• Design (and layout)
• Disaster recovery
• Documentation
• Editorial, publishing
• Efficiency (resource consumption IT, energy, human, performance vs effort)
• Emotional factors (fun, absorbing)
• Environmental tolerance
• Escrow
• Error tolerance (wrong user input)
• Error messages. (how and where)
• Ethical considerations
• Extensibility (adding features, upgrades)
• Failure management
• Failure tolerance (defect in system execution)
• Install-ability (easy to install?)
• Internationalization (e.g., different countries, languages)
• Interoperability (properly interfaced with and working together with something else)
• Language (style of writing, target group)
• Learnability (easy to learn)
• Legal (licensing issues, patents-infringement-avoidability)
• Logging
• Logistics
• Maintainability
• Memorability (easy to remember how to do thing in the system)
• Mobility (Can it be used on the move)
• Modifiability
• Multi user scenarios (collaboration, access to the same objects at the same time etc).
• Network topology
• Open source
• Operational , manual procedures
• Operability (possible to perform tasks in accordance with operations manual?)
• Packaging
• Performance / response time (performance engineering)
• Personalization (personal user experience)
• Performance (Jitter, Response time, Latency)
• Personell (and resources)
• Platform compatibility
• Portability
• Precision of data
• Price
• Privacy (GDPR)
• Provisions
• Protocols
• Quality (faults delivered or fixed)
• Reuse-ability
• Recovery (e.g. mean time to recovery - MTTR)
• Reliability (e.g. mean time between failures - MTBF)
• Reporting
• Resilience
• Resource constraints (processor speed, memory, disk space, network bandwidth)
• Response time
• Reliability (operates without failure under specified use)
• Robustness (also functions under abnormal conditions)
• Roles (Who can add, edit, delete, view)
• Safety (preventing / dealing with accidental harm)
• Scalability (horizontal, vertical)
• Schedule-ability
• Scope
• Security (tolerance against malicious harm)
• Source code
• Stability
• Subset-ability (easy to make different functionality subsets)
• Support (end user support)
• Survivability (essential services continue in spite of accidental or malicious harm)
• Style
• Templates
• Testability
• Throughput
• Traceability
• Training
• Transportability (possible to move system)
• Unambiguity
• Usability (ease of use)
• Usefulness (useful to use)
• User experience (system perceived as fun, satisfying, enjoyable, entertaining, helpful, motivating, aesthetically pleasing, emotionally fulfilling, rewarding and supportive of creativity etc)
• Validation (of user inputs)
• Verifiability
• Variability (degree to which different variants exist)
• Withdraw-ability (can a specific version be withdrawn and replaced with a previous, version)
• Workflow
• Workload (low perceived workload by user)

References

http://en.wikipedia.org/wiki/Non-functional_requirement

http://www.idi.ntnu.no/grupper/su/fordypningsprosjekt-2005/eide-fordyp05.pdf

Scrum taken to the extreme, doing design of features in the same sprint as they are to be developed

On one of the projects I participated on last year I had the opportunity to work on a large project (more than 15 participants, several locations and several interfacing systems). It was decided to do design of products/features in the same sprint/iteration as it was to be developed. This is not the ideal situation as several others have experienced before me [1],[2],[3],[4],[5] and as described by best practices [6],[7],[8],[9],[10].

The background for this decision was that the clients company profile rebranding project was not finished so the designers did not have what was needed to do the complete design job beforehand. Therefore the design team could not really start their job before the developers. Because of this it was decided to have sort of sub iterations within each sprint. For each sprint a set of products were planned and then designers started designing products as on an assembly line. As each product was designed it was delivered to the developers at once to be implemented.

About the project and team composition

Both developers and designers were quite flexible and competent. The development team had some experience with design and the design team had technical knowledge and could even do frontend programming. The project aim was to develop a new Intranet on a new platform. Re-branding was a key goal. It must be mentioned that the developers outnumbered the designers considerably. There was a fixed deadline and the total project length was about 8 months.

This is what happened

The project started out in good spirit. Everyone was confident and happy but after a while things started to go less smooth. As with all projects with a certain level of complexity there is not just one single thing slowing down production. I'll try to concentrate on the issue of in-sprint design and development (design and development of a product in one sprint).

Planning

Since design was not complete at the start of each sprint, developers could not estimate the job since they did not know what exactly they were to develop. This had the affect that the project lead did not have the slightest idea how much would be completed after each sprint.

Doing design in the same sprint as it is to be developed also made the progress flow extremely unpredictable. The time required for design is often hard to estimate and designers often meet unexpected problems in their design as we developers do in implementation. This means, without any lag between design and development, the risk of encountering blocking impediments are doubled.

Specification and Handover

As designers were to handover several smaller designs it was easy for them to to make readjustments to the design specs as these mini, continuous handovers became less formal. This resulted in frustration on the developers who had already started developing the design.

Because there were no big formal handover and the designers were already overworked it was easy for designers to get in to the trap of handing over items that did not follow the required documentation guidelines. Items got sent by e-mail and people forgot to upload it on the correct place and adding the agreed descriptions etc. This again led to difficulties in tracking changes and finding the specs.

Since the designers worked more or less in parallel with development there was always some spec lacking. Developers constantly needed to ask the designers for specs and after some time all the designer was doing was feeding developers with design. This situation where the designer was pressured also had the effect that designers did not always have time to do good overall design making the entire design harmonize. 

In other cases the designer were overrun by developers and developers started dictating the design because the designer was overloaded with work.

Another side affect was that designers had less time to prepare and get a strong acceptance on the next design. On a few occasions design did not go through a quality assurance loop with the customer resulting in bad features that had to be redesigned later. As each user story was a minor handover stakeholders could not really be involved in the acceptance of the design as it would then slow down the project considerable if several parties were to be included for each of these small sub deliveries. Instead the designers controlled the process and sought out who to contact to get the necessary feedback. This had the effect that some persons did not get the chance to see the design and give feedback before it was delivered to the developers. In some cases this proved disastrous as some important stakeholders had important information that did reached neither the design nor the development team. Some participants felt overlooked as they did not get the chance to participate in the design work or not even being able to comment on the design proposals.

Communication and noise

Often specs were not very detailed and in many cases completely absent. Less documentation is part of the agile manifesto but since we had developers at several locations this became a problem. Less documentation means more face to face communication and communication with instant messaging, phone, e-mail, but in large projects, participants tend to have a lot of meetings and thus not being available for communication about specs. Developers often found themselves sitting and waiting for people to come back from meetings when having questions about some design that may have had an incomplete spec. In other cases they just started on some other product which in turn led to a chaotic work environment when the developer ended up with working on 4 user stories at the same time. Not being able to complete a module/product adds noise in the project as the project needs to bring this product up in each scrum meeting and you have to tell once again why the product is not complete. Several products also seemed half finished since there were no complete specs and relevant persons were not available at the same time to clear up design issues.

The incomplete or lacking specs had the effect that everyone on the project needed to communicate a lot more. Time was wasted as messages had to be repeated. As much of the work surrounding specs or the specs themselves was replaced by face to face communication people outside the core group had to ask for information, this resulted in multiple and overlapping communications.

The IA/GD/UX team will always have some questions for the developers but since both design and development is done continuously and in parallel there will be a continuous flow of inquiries for the developers. Instead of having planned design workshops were designers could get feedback from developers and others, we were doing development and design in a continuous and overlapping fashion. This is not optimal for a typical developer. Developers will always be prompt and ready to delve in to planning, problem solving and answering questions in the planning phase of the sprint. But, once developers get down into the nitty gritty programming, many developers will have their head wrapped around difficult tech problems and are not in a mindset to constantly respond to small design issues put forth by designers. Many programmers are also competitive. Non-programming related distractions in the middle of the day are not always what the developer is most keen on. This had the effect that some design problems were not well thought through because the solution was based on feedback from a developer who had other more important things to think about.

Experienced developers want to know what features should be developed next so they can chunk together related work including fixing bugs on related stuff. But as they now live in this day by day design hand over they did not know what features would come the next day and ended up scratching their head trying to figure out this himself or trying to find this out from the IA or designer. The designer works on other things so there is noise. Not being able to chunk related work led to less efficiency.

Workflow, predictability and work conditions

In the early sprints developers tended to have little work in the start of the sprints as they were waiting for design. In the end of the sprint developers were often unmotivated from taking on new design since it was something completely new that they might not have seen before. Completely new design are more intimidating than a design that has been slowly setting in the developers head during the sprint and where the developer has gotten the time to figure out how to best solve the task.

As designers were fully entangled in pushing design they had little time to look over the end result and developers had to go ask designers to test if the implementation of the design was ok.

Developers did not know when they would get a design and what it would look like. This led to unpredictability and unsystematic work making the flow less streamlined and more ad-hoc.

It all became very unstructured. Some people, often the creative ones thrive in chaotic environments but for many developers, often systematic engineers, it became very messy.

For new developers, especially the juniors, coming on to the project late it must have been a nightmare not having the knowledge that had been communicated only by mouth and feeling that they add even more noise in the project. For some of the seniors on the project it did result in a lot of extra guidance and support on these new participants. Incomplete specs were even more problematic for new project participants because they did not have the big picture. So again more noise.

Technical forward thinking, architecting and code quality

Since we did not know what design would come later we could not estimate development time sufficiently, therefore the tech lead did not know if we had time available to do maintenance  refactoring and other things that would benefit the project in the long run. All he could do was either concentrate on getting things up and running or taking the chance on doing refactoring and risking not being able to complete later features.

In general there was a lot of unsystematic work and unpredictability making it harder for the tech lead to plan in advance and see where to do refactoring etc. Unit testing was out as everything was changing day by day. Setting up unit tests takes time and is a waste of time if the requirements change and the code is likely to be totally rewritten the next week.

As specs seemed incomplete or being suddenly changed developers often became demotivated knowing that what they developed would probably have to be rewritten. This resulted in lower productivity, poor code quality and features that were only partially completed.

Since designers were overworked they where not always available to do these kind of in front of the screen 2 minute designs that often are needed for some small thing that was overlooked in the design phase. In this case the developer just design the thing him self.

Testing

Some developers felt stressed out as some design was delivered just few days before the end of the sprint. Most developers want to deliver as much as possible so this results in a situation where the developer wants to produce new features but gets overworked and forgets the importance of testing or preparing for testing of what has already been implemented.

Because of poor specs, test scripts were poor and this resulted in test results that were not realistic and testers did not know what had been completely developed. Some products were set as ready for test before they should have.

Because specs was hard to find specs were in some cases even skipped. Some features were even developed without a developer looking at the specification. In some cases features were developed without a spec as there where no spec available. In many cases this was not a problem as the feature worked out quite well. The designer could then go over afterwards and suggest improvements.

Because design was immediately delivered to the developers when ready it did not get to mature and therefore some design was a bit premature and ended up as features that eventually had to be replaced. If the designers had a week or two to digest and circulate the design it is more likely that the design would be better and that it would lead to a better solution.

Coupling design specs to prototypes to issue/task tracking and to test scripts became difficult. For project participants not sitting next to the designer it was hard to know what design was finished.

Incomplete specs led to vague definitions of done criteria and test scripts were hard to write.

Summary of problems with doing design in the same sprint as it is to be developed

• Difficulties planning and estimating work
• More unpredictability and increased risk
• Poor documentation and traceablity and findability of documents
• Often change in specifications
• Design not always harmonizing
• Redesign and reimplementation because first version was not good enough
• Relevant persons are not included in the design phase and felt overlooked
• Noise, duplicate messages and repeated tasks
• More waiting for clarifications
• More difficult for new and remote participants
• Design and development cycle partly broke down
• Unit testing got more difficult and code quality got worse
• Lower productivity
• More half finished features
• Difficulties in writing and organizing tests
• Poor tests and test results
• More distractions and chaos
• Less happy team members

Discussion

Again, it is difficult to exactly know what factors led to the problems listed above. There were several other decisions that are likely to have contributed to this situation. Having analysed the situation and thinking back on other projects I do believe the list of problems are representative to the issue of doing design in the same iteration as it is to be developed.

Being a developer on this project I am certainly not without some bias, so I'm inclined to say something positive about the process. But hey, as I'm sitting here writing this blog post I can't really come up with any benefits of setting up the process this way. Doing design in iteration i+0 might work perfectly well for small co-located teams but for a project with scaling factors [11] in a large corporation having strict requirements on compliance, traceability etc with a large distributed team this just don't work very well. Agile is all about good communications [12], but our situation got to the point of communications overload and the development process almost broke down. 

What can you learn from this?

Do not do design in the same sprint as it is to be developed. The design team should always be at least one sprint ahead of the developers.

The optimal solution would be for the designers to have a complete initial design ready before the bulk of developers start development. During this design phase selected developers, stakeholders and customer representatives etc help form the initial design. During development designers are tightly integrated into the group but are mainly working on evolving the design based on user feedback and on unexpected technical limitations etc. They would also focus on specifying details or things that have been overlooked.

How to avoid this situation

Plan and make sure managers, project lead, steering committee, product owner, decisions makers or other relevant persons are aware that designers should start ahead of developers.

What to do if you end up in this bad situation

1. Have the developers implementing core features without any UI design while the designers are working on the initial design. Get the solution up and running. After all this is what Agile is all about; making sure you have something working and then iterating to improve it.
2. For projects with scaling factors [11], formal design specifications are more important than on smaller co-located projects. A person can be assigned as responsible for documentation making sure specs are in order. If designers don't have time to do deliver good specifications then someone else should be in charge of writing up and formatting the specs.
3. Make sure the project is staffed up with a enough designers. This will obviously depend on the type of project and aesthetic requirements. If there are 8 developers you might need 4 designers, such as an Information architect, an art director, an user experience designer and a graphical designer.
4. Using teams of designers and developers that have previously worked together on projects with the same technologies. This will minimize the friction between designers and developers and reduce uncertainties.
5. Designer(s) must be tightly integrated and co-located with the project.

References

[1] CHI 2009 ~ Case Studies ~ Experience with Software & System Development and Evaluation

[2] Bringing User Centered Design to the Agile Environment

[3] UX Matters - Clash of the Titans: Agile and UCD

[4] IXDA - Discussion Archives - Interaction Design in an Agile Environment

[5] IXDA - Discussion Archives - UCD and Agile Programming - models of involvement

[6] Prior to Sprint Zero: A Note on Jakob Nielsen’s “Agile User Experience Projects”

[7] Agile + UX: (un)Synchronizing UX and development

[8] IBM Design - An Agile approach to User Experience and Design

[9] MSDN - Magazine. Usability in Practice, Agile Ux Development

[10] InfoQ - Agile User Interface Development

[11] IBM - Agility@Scale: Strategies for Scaling Agile Software Development
[12] Agile Principles and Values, by Jeff Sutherland

Sprint retrospective helper

If you're a developer doing agile working with SCRUM etc. and holding regular sprint retrospectives, you've likely experienced the moment when you're supposed to note what went well and what could be improved, only to get a feeling that several important topics have slipped your mind.

A helpful habit is to jot down insights as they happen, while they're still fresh. This ensures you have meaningful notes ready when the retrospective arrives.

The list below serves as a set of prompts and keywords to help trigger your memory and inspire discussion points for the retrospective. It can also be useful for informal project evaluations. This list isn't meant to be prescriptive or exhaustive, simply a helpful guide to stimulate reflection and idea-generation.

Process
standup, meetings, deploy, DoD, control, reproduce, test, plan, demo, keeping track, improve, design, prioritize, results not lost, continuity, handling issues, stabilization, complex, analysis, integration, velocity, timing, flow, pace, think, sprint planning, charts, coverage, start/stop, tendencies, review, progress, feedback, goals, notes, board, stepping on toes, race, hand over, significant events, timeline, consensus, management, senior, anchoring, monitoring, debt, agreement, performance.

Policies
source control, decisions, documentation, decisions, hand over, scope, deadline, quality, staffing, QA, code review, recognition, strategy, vision, risk, bug tracking, issue, automation, analysis, refactoring, activities, accountability, user stories, phases, patterns, architecture, holidays, culture, flow, data creation, silo, usage, bounce, ripple effects, boundaries, PoC, skills, metrics, escalations, completing stuff, training, knowledge, help, manual steps, prototype, risk, cost, analysis, contract, load, on/offboarding, limits.

Work environment
safety, collaboration, work hours, new members, head count, organization, customer, tools, roles, stakeholders, involvement, engagement, uncertainties, environment, optimizations, tasks, motivation, change, skills, food, chaos, familiarity, fun, stress, software, 3rd party, external, actors, energy, air, sit/stand, down time, remote, crash, branch, control, difference, conformance, competition, constructive, freedom, security, fatigue, knowledge, oversight, feelings, blaim, support, initiative, mentoring, interruptions.

Communications
participants, dependence, overview, noise, sync, expectations, errors, report, backlog, requirement specification, availability, members, stakeholder, learning, loops, acceptance, rejection, hours, timeboxing, impediments, design, wireframes, goals, unity, backlog, details, understanding, agenda, conclusions, clarity, blockers, abstract, appreciations, transparency, honesty, creativity, confront, good enough, impact, consequences, questions, ask, feasibility, summary.