Skip to main content

Crystal ball - ETA chart

Given the nature of change within agile projects, it is good to try and foresee what is in store in the near future. This is where the use of a crystal ball is useful. Now, when i say crystal ball, i do not literally mean having a nice shiny circular translucent object that takes us into the future. I am talking of a chart which gives us a slight insight into what is going to be delivered. Lets call this Crystal ball as an ETA (Expected Time of Arrival) chart.

This ETA chart gives the team an insight into what is going to be delivered within an iteration. This ETA chart is a matrix where the columns represent the week days within a 1/2 week iteration and the rows are the dev pairs working on different stories. This is what it looks like



So the idea is to get the developer pairs signed up for stories to put up an ETA (Expected time of arrival) for the stories they are working on and put it against a day. So they would just put a sticky note with the story no and a brief desc of the story against a day. This ETA is re-visited and re-validated by the developers everyday after the stand-up in the morning.

The benefits a tester gets with the ETA chart are
  • The testers can plan their work better within the iteration since they have a better idea on what is being delivered first. Thus, they can focus on first writing test scenarios, writing automated tests for stories being delivered in the first week of the iteration.
  • This helps them not focus on stories that might be delivered in the second week of the iteration
  • The testers can finish up and sign-off stories being delivered within the first week of the iteration which gives them time to then focus on the stories being delivered in the 2nd week of the iteration.

Comments

Post a Comment

Popular posts from this blog

Build quality in early and often

One of the most important aspects of building good software is to encourage the concept of build, measure and learn. For companies to be able to innovate and be quick to market they must encourage a good engineering culture that sets up teams for success. In an ideal world, you should deliver to production daily. However, if you deliver software fast, but it is full of bugs, your product has a lower chance of succeeding. As an agile tester, one of your focus points has to be to speed up the feedback loop while maintaining good quality. Over the years I have laid across a few good practices that make teams build the product right and also build the right product. Engage Test Engineers as early as possible in the development cycle Test Engineers are often treated as the last stand against finding problems before release, yet like all software activity; their focus is affected by the information available to them. In order to better understand the risk associated with changes an
Post a Comment
Read more

BDD is over-rated

Over the past few years, I have tried to justify the use of a BDD (Behavioral Driven Development)  framework to express my tests, but not once have been able to say BDD has helped me address a  problem which writing tests the non BDD way would not have addressed. I do understand the value BDD brings to the table, but in most projects that I have implemented BDD on, we have tried to provide a solution (BDD) to a problem that does not exist. Let me try and explain. Lets look at the key benefits of expressing tests the BDD way (There could be more) Collaboration between Business and Development Ubiquitous Domain Language Focus on the behavior of the application Now, more often than not unless your business is co-located with the team, collaboration is not the easiest. The value BDD brings here, is the business validating our understanding by reading our tests expressed in the Given When Then format (BDD) and providing feedback, as BDD expresses the behavior of the system in a l
1 comment
Read more

Can projects do without Business Analysts?

My  last 2 gigs were a bit different to the usual ones from a team composition point of view. The bit that was different was that there weren't any Business Analysts on the team. My initial concerns were who would gather requirements? Who would analyse stories? Who would negotiate scope with the business? Who would be involved in Scope Management? Who would be our proxy customer? The above questions got me concerned, but it wasn't as bad as i thought it to be. The customer was co-located with the team and we had easy access to validate our understanding on business rules, scope, sign-offs etc. Our team composed of an IM, Devs and Testers. The IM was managing scope with the customer and getting the priorities. The team would then sit with the business to understand what the requirements were and we would create Epics and then further break them down into smaller chunks of workable stories. A thing to note here is that all roles would put their BA hat on and identify gaps if
Post a Comment
Read more