Tag: Agile

During a recent client visit I encouraged the use of modeling as a way to uncover hidden requirements and expectations. One of my clients expressed her rather strong opinion that modeling requirements was not and should not be a part of business analysis work. Oh, she could accept the fact that uncovering gaps between the “as-is” and “to-be” using process models made some sense, but she was adamant that this gap analysis should be done by a business SME, not by a business analyst (BA). As to data modeling, well that was technical in nature and if done at all, she said, it should be done by the technical IT staff. Use cases were helpful to the testing staff, but were clearly technical and were not to be done by BAs. Prototyping? This should be done by developers-no question about that one!

I was surprised at this reaction, which was expressed so emphatically. Perhaps she had no experience modeling requirements and felt insecure about her ability to do so. Perhaps she assumed that the norm for her organization was the norm for the industry. Perhaps she thought that models were truly technical in nature. Perhaps the line in the sand between business analysis and design was clear in her mind and modeling of requirements went into the technical bucket. Perhaps she thought that “solution” requirements (functional and non-functional) had no place in business analysis.

Is the real answer the consultant’s mantra “it depends?” In this instance I’m not convinced that it is. It seems to me that business analysis has to be concerned with what affects the business. If we’re creating a new web page or modifying one, we want to be sure that the navigation makes business sense (process modeling), that the information on the page is flexible and correct (data modeling), that how our customers interact with the website works for them (use case modeling). And I know that when we show people pictures, we uncover requirements that they would never have thought of.

Do these models have to be completed by a BA? No, they don’t. They can be performed by anyone in the organization who has knowledge of and experience in creating these documents. Having just said that anyone can model requirements, however, I’m now going to go out on a limb and make the case that BAs are best suited to model them. Here’s why:

1. Modeling is a great way to uncover expectations-those unarticulated requirements that are rarely revealed at the beginning of business analysis, if at all. One of the advantages of modeling is that it provides a structure that encourages questions. Business analysts are in the best position to understand this structure and ask questions of the business subject matter experts (SME)s. They also are in the best position to interpret the answers and understand the impacts of responses they receive. Also, BAs generally recognize the importance of asking a variety of questions from multiple perspectives. Creating different models (business process, data, use case, low-tech prototypes) provide these different viewpoints (more about which in a future blog).
2. Being consultants and liaisons, BAs are in a unique position to understand the business and to translate the requirements into something the designers can design and the builders can build. They can also translate the technical design back into something the business clients can understand and approve.
3. BAs who can model requirements will almost certainly see gaps that jump out at them, screaming to be addressed. BAs, it seems to me, are uniquely qualified to address these gaps in a way that serves the business and makes sense technically.
4. BAs are probably more likely than technical staff to go to the business to get questions answered. At the risk of gross generalizations, technical people may have a tendency to answer the questions themselves, without getting input from those who will be most affected-the business users.

My advice is to recognize that business modeling is best done during the business analysis phase(s) of a project and is best done be those who understand their importance in eliciting requirements.

Don’t forget to leave your comments below

As agile project management methods are becoming more widely adopted in companies around the world, many of those companies struggle with one of the most basic decisions when starting iterative incremental project approaches: what is the ideal iteration length to use? Let’s see if we can tackle that question.

Definitions

First off, for those of you new to agile management concepts, an iteration is a defined timebox during which a portion of a solution is worked upon. There is a lot of misuse of this term, as many people mix up the terms iteration and increment.

Strictly defined, an iteration is a timebox used in an iterative project model. In an iterative model, a whole solution is developed over the course of a project, with snapshot views of “work in progress” being presented to the sponsor and/or stakeholders for feedback at the end of each timebox cycle, called an iteration. In this model, the solution is not completed and fully tested until the end of the project.

In an incremental project model, the aspects (features) of a solution are prioritized and are completed in order of priority. Each increment is a timebox during which a selected group of features are completed and fully tested. Under incremental approaches, there is no work in progress at the end of any increment. Instead, each timebox adds more complete, working features to the ones already developed, growing the completed solution over time.

Agile methods combine both iterative and incremental approaches. As such, a timebox in agile (also called an iteration) defines a cycle during which an increment of functionality is completed. Yet agile tends to have a broader view of the solution than pure incremental methods (more about that in a future article).

Standard Iteration Lengths

There is no consensus in the agile community on the ideal iteration length. The Scrum method suggests 3-4 weeks as an iteration length, while eXtreme Programming and Feature-Driven Development suggest 1-2 weeks.

When choosing a standard iteration length, you should consider your team’s maturity with agile methods. Generally speaking, teams new to agile should probably start with iterations on the longer side, and then choose shorter iterations as their expertise with the new methods improves.

That being said, the shorter the iteration length, the more a team needs to rely on automated tools to help with project work. In software development projects, this means automated build and automated testing tools, primarily. This is especially important in later iterations in the project, where there is a growing list of new features that need to be regression tested every iteration – eventually, they can’t be fully regression tested by hand in the available time.

Another factor to consider is the value that can be received through shorter versus longer iteration lengths. If you have limited opportunities to meet up with the sponsor and stakeholders to make end-of-iteration demonstrations and capture resulting feedback, then perhaps a longer length might be more realistic. On the other hand, if your sponsor is very concerned about eliminating risk in the project or if you want to build trust by showing rapid delivery of value in the early stages of a project, then perhaps shorter iterations are in order. You need to think about how you can optimize your delivery of business value through your iteration length. Business value is often measured in dollars, but it can also include other elements like strengthening relationships, risk reduction, improvements in service levels, rapid learning, and many more factors.

Variable Iteration Lengths

Having a defined iteration length for your project that does not vary helps the team “get into the groove” or adjust to the cadence/rhythm of working under, within a particular timebox. This iteration cadence is important in helping the team optimize their internal processes as the project proceeds through its multiple iterations. As well, it helps the team perform at higher levels, as the members can estimate more accurately and build more accurate plans.

There is a case, however, for occasionally varying iteration lengths within a project. While this can be a controversial position with some purists, it bears closer examination. In rare circumstances, it may make sense to break the cadence of the team to include a longer or shorter iteration for specific business reasons. Perhaps you have one large piece of work that cannot meaningfully be broken down into pieces small enough to fit into a single iteration. For example, if your project is to install and configure/customize some complex packaged software, perhaps the first iteration is to perform the base install, while future iterations are devoted to the customization of that package. In this case, the first iteration could be 3-4 weeks to get the base infrastructure set up and working, while future work could be a series of 2-week customization iterations. In another example, you may have standardized on 3-week iterations throughout a project to develop a new product, but then switch to a short series of 2-week iterations to rapidly adapt to feedback from key customers once the project has reached a critical mass of functionality, or after it has been announced at a key industry trade show. In both of these cases, there is a specific business benefit to varying the iteration length – though I am careful to point out that I am not suggesting that you vary the length of each iteration; what I am proposing is that there may be business value in switching iteration lengths during a project.

Please note, however, that switching iteration lengths does not come without cost. As mentioned before, you will likely break the cadence of the team, possibly reducing their performance slightly until they adjust to the new rhythm. Also, you’ll have to be careful with how you are tracking and forecasting using velocity, as the metrics will recalibrate as the iteration lengths change. You may not be able to reliably compare pre-change metrics with post-change metrics, at least not without detailed explanations and careful consideration.

Conclusion

Ultimately, there is no ideal answer to the iteration length question. What is important is that you choose a length that is suited to your team, the technology available, and the project context, and the business case. While you may start with a default iteration length for your organization, it is wise to consider all of the above factors and adjust that default length if it will help optimize your project, while still respecting overall organizational objectives.

Don’t forget to leave your comments below.