Posts Tagged ‘programming’
You don’t demand ETA’s on shit you aren’t paying for. You don’t get angry when something doesn’t work quite right on an Alpha or Beta build of something you didn’t pay for. You don’t start shooting off at the mouth about how you are going to move to someone else’s free software if this developer doesn’t fix the software you didn’t pay for.
I was naturally in agreement with the spirit of what he said. And I think that he and these developers miss a number of simple facts: Read the rest of this entry »
I like a User Story to be precise and target a specific functionality, a Use Case or a logical vertical of a Use Case. This means that a finely scoped task of 2 or 3 hours could be called small. It also depends at what time in the SCRUM backlog a certain User Story is implemented for it to be a small or large User Story.
At the beginning of any development project all User Stories are large, they include many additional variables everything from setting up the initial design patterns, to drastic refactoring to allow for stackable functionality. This means that a task which might take 2/3 hours once there is a working vertical to build on could take considerably longer when everything needs to be build from scratch. Ron Jeffries – SCRUM God – says Read the rest of this entry »
Recently I was asked by a client to make some estimations regarding a review of a code review for a programming project. The aim of the project is to refactor the existing code for efficiency, check the security and add new functionality. Having done code reviews in the past I had an idea on how it should be done, and little idea on how to quantify the work into an estimate.
How a code review estimate is done now?
Testers are very important in SCRUM, before the sprint they help the Product Owner to refine the User Stories are help with “How to Demo” and “Definition of Done”. Doing this during backlog grooming or analysis meetings allows the Testers to suggest User Stories for testing such as in the sidebar, and allows them to product examples which can be used for automated testing, help with sprint planning, among others.
“As a Tester, I want to read a log, so that I can verify that payments have been processed”
During the sprint, while programmers will be implementing the functionality, the testers will be implementing manual test scripts, automated tests and acceptance tests associated with the user story. In some places they develop the automated tests paired with a programmer, and in others they script the tests themselves. The testers would deliver “Running Tested Features”, preferably together with the programmer, which comply with the Definition of Done which the Product Owner, Testers and Team have defined.
You can see that Testers are a vital part of any SCRUM team.
Image source: Wikipedia
Sources: Lance Walton, Henrik Kniberg