A common observation in projects that are based on iterative process models is that workload varies with iteration progress. This is particularly true for testing activities but also applies to development activities. Variation is inefficient. It means—general observations regarding stress level aside—that project members work less when they actually could work more and they need to work more during times with load peaks. More importantly, it also means that the work within the team is not ideally synchronised.
According to the Scrum guide, the only project role besides Scrum Master and Product Owner is Developer. According to Scrum-based process models, no project-relevant distinction exists between a software engineer and a tester (or a Software Engineer in Testing (SET), as some tester roles are called these days). In reality, though, such role distinctions exist. (Testing also serves as an example here. There are similar distinctions: developer vs. administrator vs. database specialist and so on.) In projects where testing is done by dedicated testers and workload is unevenly distributed within iterations, two things happen regularly. Firstly, implementations are ready to be tested and can’t be tested right away (or, worse, are artefacts are scrutinised hastily). Secondly, testers are waiting for work to be done although the backlog is ‘full’.
It goes without saying that 100 % evenly distributed workload is impossible. But one should aim at this ideal anyway. There are a few things to consider. I will focus on those that I consider the three most important ones: good estimations; stable requirements; anticipatory work mode.
The Sprint Planning (or an equivalent event type in other agile frameworks) is a crucial event in this regard. Basis of a good planning event is an accurate estimation in conjunction with realistic capacity planning and velocity approximation. Here, one sometimes sees the weirdest things go wrong: for instance, estimations without velocity; velocity without capacity; velocity approximation based on one iteration; all estimations within the range of two Fibonacci units; etc. For a good Planning event, get the basics straight. Ideally, use ideal time as your estimation technique. Regularly check the accuracy of your estimates and improve them.
Agile approaches are common in almost every software development project in non-regulated markets. Even in regulated markets they become increasingly common. Nevertheless, many decision makers miss basic considerations that need to be taken into account. One is the stability of requirements. In many contexts, requirements are relatively stable. Oftentimes, requirements are even extremely stable, i.e. immutable. However, the default iteration cycle in the majority of software engineering projects is two weeks, while the Scrum Guide offers are range of one to four weeks. As the overhead is higher with shorter iterations, it is usually suggested to aim at lengthier iterations. The limiting factor is the volatility of requirements. The more volatile the requirements, the shorter the iteration cycle. So, if your requirements are stable—as is most commonly the case—try to go for four-week iteration cycles.
Good anticipation skills help a lot in normalising the iteration workload. Invest in good backlog management. This concerns both the Product Backlog as well as the Sprint Backlog, if applicable. The Product Backlog is often neglected and only used as some kind of ‘reminder’ of what is left to do. The Sprint Backlog, on the other hand, is often not taken seriously at all. It’s just the top x percent of the Product Backlog that is supposed to be finished by the end of the upcoming cycle. Both approaches do not pay off in the long run. A well-designed backlog is the basis of adequate planning. And an iteration backlog should be a coherent unit. This is why almost every experienced agile coach would advise to start Planning events with a definition of a goal and derive the Sprint Backlog from it. In reality, it is just the other way around. The ‘goal’ is usually a post-hoc name for an arbitrary collection of iteration content.
An anticipatory work mode is a particularly useful skill of a tester. As a tester, be always ‘one sprint ahead’. Arrange a Jour Fixe with fellow testers to regularly check the Product Backlog, ideally right before backlog-related events such as refinements or plannings. Your regular work mode should be: In a given iteration N, work on material from iteration N+2. By doing this you make sure that whenever you enter a Planning event of iteration N+1 you have all your required work artefacts ready and, hence, need not adjust your ‘internal’ planning after the event. This reduces the level of stress of testers significantly, it contributes to a smoother workflow within the iteration, and it fosters overall higher quality of testware.
If you’re confident enough, establish processes that facilitate such an anticipatory work mode. There are several ways to do this. One important lever is the Definition of Ready, if such an artefact exists in your project context. Also, you could use workflow restrictions of your issue tracking system, if applicable. Sometimes, you come into projects that have already started. In such cases, do not focus on ‘healing’ project artefacts of the past. (Your current iteration cycle belongs to the past already.) Instead, focus on establishing an adequate work mode first, then, if required, work on the quality of done work items.
No responses yet