Velocity

According to scrum values, velocity is how much product backlog effort a team can handle in one sprint. Velocity is used for predicting when the project will be done. When a project is started we have a general scope, a projected cost, and a probable date. When we go sprint by sprint we learn more about the scope based on the reality of the situation. We go faster or slower, may find better opportunities or challanges. So predicting when a project will be over based on velocity may not work out well as mostly seen in agile or scrum based projects.

Lets take a different approach and ignore velocity and capacity and work based on a goal. The team with the product owner selects a bunch of items of high priority for the next sprint and establish a goal for the team to meet. As the sprint moves either the items which were more than the team could  do be removed or get more PBI's that could fit into the goal into the sprint if they have the time for it. At the end of the sprint the Product Owner, Team and Key stakeholders can inspect and adapt based on what was completed.

If we used short cycles of development of a week to 2 weeks at a maximum which will give a quick feedback on the progress towards our goals, commitments and projections. A build up chart might help to gauge how far we have progressed towards our goal. Any time a team spends on worrying about velocity or capacity is waste and not adding any value. It slows down progress, impedes agility and robs time and effort that could otherwise go to creating value.

Use last sprint's velocity as a guidance to what can be done in next sprint but focus on goal and measure progress based on how far or near you are to your goal and make changes that help you to get to your goal.

Cucumber and SpecFlow are collaboration tools

Cucumber and SpecFlow are collaboration tools and not testing tools.

From "The Cucumber Book" “Cucumber might just seem like a testing tool, but at its heart it’s really a collaboration tool.”

With cucumber/specflow scenarios we are collaborating more because the story is told in a way that's accessible to all participants (Developers, Testers, Domain Experts and Product Owners). It also helps us to define a ubiquitous language for a requirement from a end user perspective.

The Given-When-Then scenarios becomes an executable documentation accessible to non-technical stakeholders as a means of seeing what the system can and can not do.

The tests system and regression tests tell the how we do it part of the story. In short the cucumber/specflow executable documentation will explain what the system can and can not do and the Tests that the testers will run will detail on how it is implemented.

ie the cucumber will explain the business requirement that is fulfiled and the testers test will be a script on how it is implemented in the system. Both are complementary to each other but are really seperate things.

Step definitions/Fixtures are the developers interpretation of the story. So they are not specifications nor tests rather a glue to the specification and tests and the reason they would change could be the story of the underlying tests changed due to one of the reasons below

1. The product owner changed the given when then scenario on what the system can do

2. Developers changed the way the interpreted the specification due to refactoring or reorganising of code.

Or in short the domain evolved and so the domain language evolved and new concepts were added and existing ones were better understood or changed.

The step definitions will be the developers telling the product owners that we thought this is what you meant. With a clean code base in addition to a consistent levels of abstraction and good naming developers and product owners can look at this and get a better understanding of what is being built.

Instead of relying on just scripted documentation from the testers and just Test driven tests from the developers the true value relatively comes from relating requirements to implementation in a way which is accessible to business stakeholders and encourages converstation and is executable at the same time.

* Given-When-Then (What)

* Step definitions ("...Thought you meant...")

* Tests (How)

Caution on testers using cucumber/specflow for writing tests

It is tempting for the testers to use specflow for writing scripted tests for the following reasons

1.Its easy to add new tests using existing step definitions

2.Can easily change the parameters to test edge cases which means opportunity to add many data scenarios

The problem we could get into in that approach is we may end up in

-too much details

-we may miss the big picture

-they will be a lot of repititions and we may end up in a lot of scenarios

scenarios in cucumber should be focused on the business user. The language should be kept very informal. It is encouraged to keep their words as much as possible. Business users will not be talking in terms of clicking a button or a popup etc. The code underneath will do whatever is necessary to make the business scenarios work.

If something is a given do whatever is necessary to make it work. ie setting up the data or mocking/hacking a model etc

The when is the event that causes the behavior you're interested in. You should do this from the highest level you can. This is the core of your scenario, so you shouldn't be hacking data in here.

Do not put UI concerns into feature files. Surfacing UI concerns on a feature can make it brittle to legitimate design changes, and also rather boring to read.

Be deliberate in your use of domain language

When writing your scenarios keep in mind that you are writing them for two audiences: the person the feature is for and the person implementing it. Check the wording to see if you can spot anything from neither the problem nor the solution domains. If you find you are using language from outside those domains, you might be over-specifying the implementation or specifying unnecessarily broad requirements that mix concerns.

If you really care about how the behaviour is implemented, you should probably be specifying that elsewhere in a more fine-grained story – in other words chunking down to provide more detail – that won’t be interesting to the audience of this one. If not, you might want to push the detail down into the implementation of the steps.

The most important thing about BDD/ATDD is to talk to people. Please try to do that and not let the tools prevent you from doing it.

Grooming

Scrum doesn't give a clear cut idea on grooming which is actually one of the most important practices in an agile project.  A well groomed product backlog is one of the basic tenants for a successful agile project. From a well groomed product backlog you can pull out stories to a sprint and comfortably complete the implementation with less uncertainties.

Unfortunately most projects in the initial stages have a tendency to use product backlog to push stories into the sprint without a proper grooming more due to ignorance. We are agile so we don't want to spend too much time on grooming. Once the story is picked into the sprint and when worked on we will discuss the details. The problem is that if we start learning what needs to be done while working on a story the is likely hood that there will be scope creep. Working on the details will expose more questions and might even end up in the story not being completed or completed without the whole business value or quality and overall trust on the team will be effected. You don't want to spend the sprint to be used to figure out the business need and struggle to keep up to the commitments. This more sounds like waterfall model inside a sprint, ie first find the requirements, develop the code and then put it for testing. If the business is not reachable within the sprint it will add more problems. If there are external project dependencies it gets even more difficult.

If we can apply grooming the right way which is to 1) discuss the story first to find out if it is the right story in terms of priority, test ability and feasibility. 2) if it is in the right size and priority then discuss the acceptance criteria in terms of a common understand by 3) bring out the scenarios that can be used to define the scope and help define the defenition of done based on acceptance criteria so the team now only needs to pull it into the sprint and work on the implementation details.

How can this be achieved. It is very important that the team understands the business need of the story. Spend about 10% of capacity of the current sprint to groom stories for the next sprint. Grooming will include Identifying the user and need for the story to the business and the scenarios that will define the story to be done based on the acceptance criteria identified for the story. This will reduce the time on planning and help estimate tasks for a story.