Are there any reasons not to accept a software deliverable as a virtual machine?
This is a question about logistics, not a technical question.
Include internal defects into the release notes?
When delivering a product, Release notes clearly contain known issues found by customer in the previous build.
But should we include defects that we, as a supplier, found during our testing, those unresolved and hence present in the build?
I mean, it makes sense to me but I would love to know what more experienced people think about that problem.
Include internal defects into the release notes?
When delivering a product, Release notes clearly contain known issues found by customer in the previous build.
But should we include defects that we, as a supplier, found during our testing, those unresolved and hence present in the build?
I mean, it makes sense to me but I would love to know what more experienced people think about that problem.
Team focusing on tasks, but not on User Stories
We have an architecturally layered application, with web frontend, java backend, java and python microservices, DB etc. so when we do a User Story representing business value, it’s mostly broken down into 2-5 different technical tasks, worked by multiple people (we have tech specialization rather than cross functionality unfortunately).
The problem is that it seems everyone is focused on delivering their tasks only, and at the end of the sprint we oftentimes run into problems of lack of integration between layers and User Story doesnt get delivered end to end or a lots of bugs appear right becore the sprint review.