written by gunther gerlach-2009
A user story describes desired functionality from the customer (user) perspective. A good user story describes the desired functionality, who wants it, and how and why the functionality will be used.
The INVEST model define a User Story as Independent, Negotiable, Valuable, Estimable, Small, Testable. Let’s see what each one means:
Independent - One user story should be independent of another (as much as possible). Dependencies between stories make planning, prioritization, and estimation much more difficult. Often enough, dependencies can be reduced by either combining stories into one or by splitting the stories differently.
Gunther Gerlach
written by gunther gerlach-2009
Recently I came across of someone posting about the value of a PM in an Agile Scrum environment. It’s been a long time from most of the companies realized the important role of PMs But it looks like some Scrum process consultants, after run out of ideas to justify the PM’s role, they just wants to get rid off them… big mistake
Gunther Gerlach
written by gunther gerlach-2009
Velocity is a measurement of how much the team gets done in an iteration (called as Sprint in Agile Scrum). Velocity is what actually got done in the last iteration not what is planned and is calculated by the number of story points done in a certain sprint.
In Scrum it is measure in Story points. Each feature in scrum is a story. A story has points. Points can be anything you come up with.
Examples are 1, 2, 4, 8 , 16
Gunther Gerlach
written by gunther gerlach-2009
In Agile Scrum management process, there are few needs to happen for the sprint (iteration) to be called done. There are at least three types of Definitions of done.
Story Definition of done
· A Story definition of done would look like this.
· All stories should have automated acceptance test.
· The story should have working code supported by unit test that provide around 60 – 70 percent coverage.
· The story should have well defined acceptance criteria.
Gunther Gerlach
written by gunther gerlach-2009
An XP practice where two programmers work alongside each other, trying to get a task accomplished. Two minds at one problem!
How this help?
· It brings up productivity if the pair knows what it is up to. A chatty pair can cause more damage to the project than getting done
· It keeps each person honest. If you don’t know something its apparent in the fifth minute.
· It helps keep the quality of the code. Since the pair is helping code.
· This is where design happens.
Gunther Gerlach
written by gunther gerlach-2009
How it works: Select a regular time period over which to measure project velocity. If you’re using fixed Sprints or iterations, use that time period. Otherwise you can use weeks, fortnights or months. It doesn’t really matter which as long as you’re consistent. Add up the estimates for all the tasks/deliverables/features in your chosen time period. It doesn’t matter whether the estimates are in days, hours or even in relative story points. Only include the estimates for any items that are 100% complete and signed off within the time period. Anything still in progress counts as zero, as there is no value in incomplete work.
Gunther Gerlach
