Demonstrating and Validating the Sprint for Developers – Part 2

Accepted Deliverables

If a deliverable is accepted, developers have successfully finished work on that specific feature. They can then move forward with other work in the product backlog for the next sprint. Even if stakeholders requested minor tweaks and design changes, developers can incorporate that into future deliverables. However, anything that is less important than the highest priority tasks in the product backlog will be postponed until later. Revisiting features that technically work, if not quite how the stakeholders envisioned, may give less value to stakeholders than new features that have not yet been created.

Rejected Deliverables

If a deliverable is rejected, it still requires some work to be finished. From this point, the Scrum team and developers in particular can go in a few different directions. A rejected deliverable is evaluated based on priority like any other task in the backlog. Typically, rejected items are usually scheduled to be worked on immediately. This is common for a few important reasons. Most importantly, this code is still fresh in the minds of developers who worked on it. Instead of having to come back to an issue weeks or months later, they resume work almost immediately. This reduces inefficiency, and addresses the issues that caused rejection quickly. Another benefit is guaranteed value in fixing these deliverables. Where new development has the potential to be accepted or rejected, fixing a rejected deliverable is almost certain to yield an accepted deliverable.

Rejected items that fall lower on the priority scale are inserted into the product backlog at the appropriate point. If the Product Owner defines the rejected deliverable as less important than new development, then the overhead of research is worth the delay. The entire goal of Agile is delivering valuable features to stakeholders. Developers create the software, but it is not their responsibility to determine what is most valuable, and what to work on.

Deliverable Confusion

Occasionally, there could be confusion on how certain features are intended to work. In these cases, stakeholders may be hesitant to accept a deliverable that is indeed what they requested. To remedy this, developers may be required to explain how a feature is working as designed. The software is intended to be intuitive and straightforward, but some features need explanation. Developers know best how software features work and can address stakeholder concerns most directly.

When deliverables are frequently rejected, the Scrum team needs to re-evaluate their process. There could be a problem in the intermediate steps between stakeholders and developers. Stakeholders give general requests of what they want the software to be capable of. The Product Owner and analyst roles on the Scrum team turn these requests into user stories and individual tasks for development. If deliverables are rejected, the issue could be in how tasks are created from stakeholder requests. With all roles working together properly, developers should be able to successfully create deliverables, and rejection should be rare.

Clearly, developers have an important role in software development, and in demonstrating and validating specifically. Even if many consider development finished after deliverables are created, there is often much more work involved for developers. Their understanding of software features and expertise in fixing problems with deliverables make developers valuable through to the end of Agile software development.

<– Continue Reading –>

Our Book Recommendations

We found these books great for finding out more information on Agile Scrum:

Master of Agile – Agile Scrum Developer With 59 Seconds Agile (Video Training Course)

Introductory Offer: Free Course