written by gunther gerlach-2011
This is a list of the most common mistakes that I have seen again and again along my career in small and large corporations in their intention of implement Agile as the primary development process. I hope while you are reading this, help you to understand what is the logic behind every single practice and try to adapt (shape) to fit into your environment. Remember, the goal is not just follow the best practices but to achieve the goals behind each one.
Read more…
Daily Scrums
Gunther Gerlach
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
Use Cases: are in fact such a clear description of a feature, and the fact that each Use Cases could stand alone. They made it really easy to move cards representing the Use Cases around the
As a difference between this methodology from the others is that Agile Development teams capture requirements at a high level only, just-in-time for each feature to be developed. Agile scrum methodology requirements are ideally visual and should be barely sufficient, i.e. the absolute minimum required to enable development and testing to proceed with reasonable efficiency. The rationale for this is to minimise the time spent on anything that doesn’t actually form part of the end product.
Gunther Gerlach
written by gunther gerlach-2009
Use Cases: are in fact such a clear description of a feature, and the fact that each Use Cases could stand alone. They made it really easy to move cards representing the Use Cases around the whiteboard, as a way of managing progress. The downside of the Use Cases is that they are a little complicated. When you look closely, they’re not that complicated really. But they tend to need a Business Analyst to write them. And they tend to be a bit off-putting for end users or business people.
Gunther Gerlach
written by gunther gerlach-2009
Define your Sprint duration: A Sprint is a key when agile scrum process is implemented in SDLC. The Sprint defines the amount of time where a team will release a feature or list of features from a giving sprint backlog. This is an important decision. Scrum suggests 30 days, but they could a week if you estimate that will improve your team efficiency. The optimum Sprint duration depends on many factors. I suggest going back to your team and analyzing the perfect duration to be able of releasing a piece of software. I suggest 14 days, plus a planning day for your team and Stake Holders to create the product backlog prioritize requirements form different teams and, analyze the product burn chart. This will leave 2 weeks of intensive work and also, two Sprints a month.
Gunther Gerlach
written by gunther gerlach-2009
If we go back to the basics, I would define User Stories as a simple tool of communication to capture user requirements throughout a project based on the business requirements and stake holder’s needs. This is a perfect, easy and fast alternative to writing extensive requirements specifications to start developing. While the technical issues and integration problems are hard to find with a simple overview of the business or technical requirements, the user Histories give some time a better overview of the details by a simple and descriptive walk, step by step by every process.
Gunther Gerlach
written by gunther gerlach-2011
