Done With A Feature. So What’s Next?
Let's define done in a way that ensures efficiency and prevents creep.
Join the DZone community and get the full member experience.Join For Free
Often a scrum team decides to implement a feature in a sprint, codes it and sends it to testing. At this stage, the product owner, scrum master, and the team often get a false impression that the feature is almost done and what remains is just testing and releasing it to production. Right?Wrong! Experience has shown that this only the start. The battle is only half won and there are many hurdles to get that feature to the finish line.
Our scrum team went through several sprints where we thought we were ready to release a feature to production but “something” came up towards the end of the sprint and we failed to deliver. We slowly came up with this checklist to ensure that what we had was checked all boxes before we showed the green flag to our product manager.
— Depending on the complexity of the feature, arrange a short demo of the feature for the team and the product owner. QA should be present at this meeting so that they understand how to test. It's also important for the product owner to understand if the feature implementation follows the desired business rules and iron out any discrepancies. Several times things like security, acceptable data, and acceptance criteria need to be clarified. It just helps in the last-minute “We forgot about this .. ” type scenario.
— Wait until QA signs off. QA will often find defects in the feature and report the same to dev. QA also needs to understand the acceptance criteria before creating a defect. Find answers to questions like:
- What data will the business enter?
- What data is invalid and should not be allowed?
- Who are the users and what is the security associated?
— Consider end-to-end testing. Depending on how this feature fits into the overall product a round of end-to-end testing should be carried out. Time should be allocated in the sprint for this activity. A feature is usually implemented over a couple of sprints and so this end-to-end testing is critical to ensure all pieces fit together.
—Integrating with the rest of the product. Ideally, this should be covered in the early stages of the feature however it does not hurt to review this once more. Often technical limitations might cause a feature to be modified and some business needs might have been deferred. Some questions that need to be answered at this time :
- Does the feature talk to the rest of the application?
- Does it modify any data so that other features might be affected?
- Is any other feature affected because of the release of this one?
— Err on side of caution. As a conservative QA, I like to err on side of caution. Having a backup plan has always served me well. Risk determination is one of the most important tasks of a QA.
- How critical is this feature to the business?
- Does this feature touch a critical feature that might result in P1?
- Do we have or need a backup plan for rolling back the feature?
— Automated testing. With teams relying heavily on automated tests the impact of the feature on existing automated tests should be considered. This is something that should be considered earlier on in sprint as well. This risk to automated tests can be managed in some of the ways below:
- Allocate time in the sprint for modifying the impacted automated tests.
- Use feature flags or toggle functionality to enable or disable the feature until automated tests incorporate the changes.
- Move the impacted tests to manual testing temporarily until automated tests are coded.
Ultimately ensuring quality is the responsibility of the entire team. The above strategies are just a step towards implementing this tenet. And with agile, the team is empowered to drive the strategy and do what’s best to deliver a quality product on time.
Published at DZone with permission of Suparna Shaligram. See the original article here.
Opinions expressed by DZone contributors are their own.