"It’s Effort, Not Complexity", by Mike Cohn, and the relation (?) between Story Point estimation and Time

Mike Cohn establiches a relationship between Story Point estimation and Time, a relation which is not consensual.

He says it better:
"Suppose a team consists of a little kid and a brain surgeon. Their product backlog includes two items: lick 1,000 stamps and perform a simple brain surgery – snip and done. These items are chosen to presumably take the same amount of time. If you disagree, simply adjust the number of stamps in the example. Despite their vastly different complexities, the two items should be given the same number of story points – each is expected to take the same amount of time."

Take a look. It's in here:
https://www.mountaingoatsoftware.com/blog/its-effort-not-complexity#.WR3nW4OtKng.linkedin

Have fun! :)

"User stories are not requirements", by Emal Bariali

Interesting article that deepens the role of the Business Analysts, and makes it go the extra mile!

The takeaways from the article:

1. Recognize that your output as a BA has huge downstream impacts.
2. Understand that meeting the needs of your downstream stakeholders (the dev team) are as important as meeting the needs of your upstream stakeholders (the business side).
3. Learn what it takes to make sure your downstream stakeholders have what they need to build a solid solution.  A little bit of "systems thinking" will take you a long way to help meet the developer needs.

I would sum it up in something like this:

1. BA work is crucial for downstream 'stakeholders' *
2. The BA works for up and downstream 'stakeholders'
3. Do some System Thinking to be sure the requirements are fully understood by downstream 'stakeholders'

* not sure I agree with this term but it works for now...

It's worth to take a look :)

Here's the full article: https://www.linkedin.com/pulse/user-stories-requirements-emal-bariali-mis-csc?trk=mp-reader-card

Have fun! :)

User Stories too long? Split them!

If a story is too long, break it down in smaller stories.

But what is to be considered a big story? And how to split it in a way that is logical?

Here's a very interesting roadmap one can use to break stories using a logical approach:
http://agileforall.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf

Further reading about breaking User Stories can be found here:
http://blog.gdinwiddie.com/2011/05/01/splitting-user-stories/
http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/
http://www.infoq.com/news/2011/04/how-to-split-user-stories

Enjoy! :)

Agile User Stories - Always "INVEST"

In Agile Methodologies, user stories are a way of implementing a set of principles that enrich the methodology application in projects, and ultimately, enrich the way we work.

Those principles are sumarized in the acronym INVEST, that help to define the story quality and even concluding it is poor/deficient, and therefore should be redesigned.

In order to qualify as a quality story, it should be INVEST, that is to say:
- Independent (from all other stories)
- Negotiable (it is not a fixed and unflexible set of criteria)
- Valuable (it must add value to the functionality to implement)
- Estimable (in a realistic approach)
- Small (it must fit in an iteration, and preferably not fill it completely! :) - see more on tips on splitting stories)
- Testable (ensuring with no doubt that it is implemented without bugs)

See more: http://guide.agilealliance.org/guide/invest.html

And have fun! :)