I hope the above two examples give you an idea about how different the projects use agile principles based on the nature of the project. And I believe this would give you some tips if want to adjust the existing agile practice in your project too. So, the BA’s who have not worked in agile projects before, now you know how the real world agile projects are….

If you surf the internet for ‘agile project methodology”, you may get lots of web pages explaining a similar set of activities which are /should be followed in Agile projects.  Unless you have working experience in an agile project environment, you may imagine what a well-defined and smooth process the agile projects have!! 

What if you have really worked on an agile project, would you have the same perspective? Especially if you are a Business Analyst or an Iteration Manager…. ? Those BA’s and IM’s… I know what your answer is and the long explanation about your agile project experience is.. I can imagine even your annoyed faces …

Whether you’re purchasing a package (also called commercial off-the-shelf, or COTS, products) as part or all of the solution for a new project or implementing a solution in the cloud, you still need requirements. Requirements let you evaluate solution candidates so that you can select the most appropriate package, and then they let you adapt the package to meet your needs.

Having discussed fields intended to name record instances, we move on to fields intended to satisfy the need to say something quantitative about a record. A quantity field requires particular attention be paid to its unit of measure (UoM) and precision. 

Sometimes the best solutions are right in front of us, hidden in plain sight. Get in the habit of working from first principles and you’ll find it easier to cut through preconceptions to change the business question and quickly see alternatives that you may have missed.