Software the Agile Way....

http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ INVEST in Good Stories I -  not overlap in concept N - the  essence, not the details V - valuable to the customer E - We don't need an exact estimate, but just enough to help the customer rank and schedule the story's implementation S - Smaller stories tend to get more accurate estimates. T - Writing a story card carries an implicit promise: "I understand what I want well enough that I  could  write a test for it." SMART Tasks S -   S pecific  enough. helps people understand whether the tasks add up to the full story. M - The key  M easure   is, "can we mark it as done?" A -  The task owner should expect to be able to  A chieve  a task. R -  Every task should be  R elevant,  contributing to the story at hand. T - A task should be  T ime-boxed : limited to a specific duration. This doesn't need to be a formal estima...

Whiteboards and stickies. Start with the basics and get the teams involved before you invest in tools. At this point, tools are detrimental. Learn the game before investing.  Some things you should think about:  1. Who's your audience?  2. What value are you capturing?  3. What type of measurements do you want visible?  4. Who will actually be using the tool?  Keep retrospecting with the team over a few months while working the stickies and the whiteboards and the team will define the requirements. Compare this will the foreseen business value from your stakeholders and you should be able to drive a decision.  Lastly, don't buy something that has too many gadgets; that defeats the simplicity of agile.  

1. Eliminate Waste 2. Build Quality In 3. Create Knowledge 4. Defer Commitment 5. Deliver Fast 6. Respect People 7. Optimise The Whole In the future posts we will discuss the above mentioned principles.

How should we handle reliability, availability, portability, scalability, usability, maintainability in Scrum product backlog? These are constraints which should be part of either the Tasks of a backlog item/user story or acceptance criteria. Example - Data migration projects where no business functionality/features are there we just need to create a utility which will migrate the data. For such requirement, we can create a user story which is to create the utlity which will allow me to handle the data migration and its tasks should have the constaints like  reliability, availability, portability, scalability, usability, maintainability.

Kanban is just a device for a "pull system" to realize Just-In-Time . Just-In-Time can be paraphrased as "making and delivering what is needed, just when needed, and just in the amount needed." It aims at meeting a customers' need: "the best quality product at the lowest price as soon as possible." 

Try the INVEST acronym. If you just google this, you should find a few links.  One should try to have Stories be:  Independent  Negotiable  Valuable  Estimatable  Small  Testable  Also, a popular format used is:  As a <Persona> I need <some functionality> so that <benefit>.  Acceptance criteria is critical to get before sprint planning as this removes any ambiguity of what has to be delivered and how it will be accepted. That is if you can prove the acceptance criteria (and your other DoD) then the product owner has to accept it. If suddenly a "Yes, but it doesn't do", the answer is simply "Not in the acceptance criteria, add this to the backlog and prioritise when it should be done" 

DSDM originated in England, has become popular in Europe, and has a number of sites using the approach in the U.S. 1. Active user involvement is imperative. 2. DSDM teams must be empowered to make decisions. 3. The focus is on frequent delivery of products. 4. Fitness for business purpose is the essential criterion for acceptance of deliverables. 5. Iterative and incremental development is necessary to converge on an accurate business solution. 6. All changes during development are reversible. 7. Requirements are baselined at a high level. 8. Testing is integrated throughout the life cycle. 9. A collaborative and cooperative approach between all stakeholders is essential.

http://implementingagile.blogspot.in/2011/06/scrum-metrics.html - Quality -Productivity -Satisfaction -ROI

Individuals and interactions  over processes and tools Working software  over comprehensive documentation Customer collaboration  over contract negotiation Responding to change  over following a plan