One of the most difficult aspects of any IT project is task estimation; how long will it take to complete a task. Traditionally, task estimation for IT projects served as a swag for budgetary and release scheduling needs. As organizations have moved toward an Agile approach in the hopes of releasing software faster, task estimation has taken on even more significance given the relatively short timeframes associated with Sprint deliverables. Accurate task estimation can mean the difference between achieving the Sprint goals or failing the Sprint and having to carry over stories into the next Sprint. What’s more, with Agile information radiators alerting the entire team in real-time of failures, knowing how to estimate has become an important skill for QA Teams. QA Teams need to be heavily involved in Sprint Planning to ensure that proper time is allocated for testing tasks. In this article, we examine how a QA Team can effectively estimate tasks in order to have the proper work load and avoid carrying over stories.

IDEAL TIME
One of the simplest mistakes that QA Teams can make during Sprint Planning is assuming that they have 80 hours to work with given a 2 week Sprint cycle. The reality is that in an ideal 2 week Sprint cycle there are at least 10 hours of meeting time required (Sprint Planning, Daily Stand-up, Sprint Demo, Retrospective) and a few unanticipated interruptions to account for (especially for QA Teams given that finding bugs interrupts the process of testing). Believing that team members will have 8 hours a day to work on tasks isn’t realistic so make sure to not confuse “Ideal Time” for work time during Sprint Planning. As team members gain experience doing certain tasks throughout the life of the project, they will naturally get more efficient at doing those tasks so don’t expect every task to be linear in terms of time. By the same token, tasks team members have never completed before will likely take them longer to complete. Each team member should keep track of their ideal time during each Sprint and use the average for each day for future Sprint Planning.

STANDARD TASKS
The point of Sprint Planning is not to detail out and estimate every task; rather the goal is to understand what work needs to be completed during the Sprint. Going into a Sprint Planning meeting, the QA Team should have a list of “standard tasks” for each User Story. For example, one standard task might be to create test cases for each acceptance criterion of a User Story. Having a set of standard tasks will allow team members to focus on the primary goal of Sprint Planning (what needs to be completed) while also having the shell for tasking out each User Story. What’s more, team members can focus on special tasks required for each User Story (usually introduced by design, implementation, or functional complexity) such as needing to build a stub to complete a test. Standard task estimation should not be linear over the duration of an entire project and will need to be reviewed per Sprint based on historical team data.

NEGATIVE TESTS
One of the benefits of having well defined acceptance criteria for User Stories is that system functionality is often well defined. One of the short-comings of acceptance criteria is that they often lack definition in what the system should not do and how to handle errors and exceptions. Focusing the Sprint Planning around just the “critical path” can lead to estimation problems because errors and exceptions are more difficult to code and defects tend to cluster in those areas. Make sure the team clarifies the “negative” acceptance criteria during the Sprint planning so they can properly include estimates for that work. Be cautious; don’t bog down the Sprint Planning meeting trying to identify every “negative” acceptance criteria, rather, use one-on-one time with the BAs and the Dev team during the Sprint to hash out the details.

SET-UP TIME
A fairly common mistake in task estimation is forgetting to include set-up time for testing. Set-up time can include an activity like getting proper access to the database in order to validate proper data transmission, processing, storage, and retrieval. For systems with different user levels, getting those user levels set-up properly and tested for use can be a tedious and time consuming effort. It can be especially difficult if the team doesn’t have a system/network administrator to help out and will have to fill out a change request. Make sure you plan for the dependency and articulate it as part of the task estimations. With the introduction of mobile requirements, another specialized set-up task to be mindful of is configuration testing set-up. Managing a large variety of mobile devices, each set-up as an environment unto itself can be difficult and time consuming. Think ahead and consider set-up time as part of task estimation.

TEST AUTOMATION
In an Agile environment, Test Automation is a requirement. Planning to incorporate test automation into each Sprint and every story can be daunting but not impossible. During Sprint Planning, the team should look to answer two simple questions about each acceptance criterion: is it automatable and how complicated is the automation? Understanding if an acceptance criterion is automatable is important for two reasons: it allows the team to know whether or not the acceptance criterion is well written and has enough detail to automate and it helps make the decision about why the time put into the task will significantly return value. Once the team has established that an acceptance criterion can be automated, conduct a check on complexity to determine how much time is needed to complete the automation task. Make use of the Fibonacci scale to determine complexity in order to stay consistent with the estimation model within Agile. Remember; don’t bog down the Sprint Planning meeting trying to exhaustively think about every detail, save that for the work during the Sprint. Some standard tasks to help avoid engineering automation during Sprint Planning could be “automation design, automation engineering, and automation review”.

Summary
Providing estimates for your work will always be a part of IT projects regardless of what process methodology a team uses to get the work done. In Agile, estimation takes on more significance because the timeframes for getting work done tend to be shorter and the results of the estimates are much more visible. To help make the estimation process more efficient, this blog offered up 5 areas to focus on during your team’s Sprint Planning meeting. Make sure your team is conscious of these areas while planning and don’t forget to use the historical data from previous Sprints to help guide your team in making better estimates.