Tag: Agile

In my last post I discussed the role of BA as it relates to working within agile teams and tried to explain what you can and should do as part of your team. One of the comments I received related to the role of User Interface Designer in agile. I had implied a complementary role in the post and the reader was looking for a bit more information. I thought it was a really good question and it’s led to this follow-up post…

Applying user interface design in agile methods is one of the leading challenges right now within the agile community. Since it’s an early-on activity, as is any design activity, the notion of sprinting till your done-continuously delivering working software iteratively doesn’t seem to engender much in the way of design.

Thus the challenge…

What design practice has done is encourage the agile folks to slightly reconsider their models. For example, within the design space, it is often quite reasonable to do design work within an iteration, that will only be ‘used’ in subsequent iterations-say the next one or two. This sort of look-ahead from a design perspective is required as the team can rarely implement the work within the same iteration where the design was explored and defined.

The trick is to not look-ahead too far. If you do, you fall into the waterfall trap of designing everything in advance, before you’ve actually gotten a few lines of code to work. (Something we agilists describe as BDUF – or Big Design Up Front and a common anti-pattern of agile development).

So this creates a need to oscillate or balance activities within your agile teams between some look-ahead tasks such as architecture, analysis, and design and then transitioning to coding and testing. I think the best agile teams ‘get’ this balancing act early on and understand that they have to work on both sides of the equation.

There are a couple of tools within the agile arsenal that foster look-ahead. I’m going to speak to a few. While they’re often ignored by the more purist-focused agile methodologists and teams, they are indeed a quite viable tool-set for looking before you leap into iterations.

• Chartering. In the same spirit as traditional project chartering, agile chartering focuses on developing the why behind the project. Usually it targets the business case for the project including: target customers, vision for the project, ROI information, budget details, high level scope targets, team and capabilities information, and definitions for success – usually including a schedule or date target. The charter should serve to energize the team by sharing the why it matters behind the project or effort.
• Research Spike – User Story. At times you really don’t know enough to write a solid user story. Usually the gap is in technical or design experience and what you really need is a little time to “play around” with things to gain a better clue. The output of a research spike isn’t working code. Instead it’s knowledge – usually in the form of architectural design details and a refined set of user stories destined for implementation in a later iteration. As a rule of thumb, I usually see 20% or so of stories in my backlogs that warrant a spike to gain more clarity.
• Iteration #0 or Sprint #0. Quite often agile teams simply dive into their work, iterating before they have a clue to where they’re going. For some projects, this seems to work and the team figures out their direction along the way. For many others, this is a disaster. Jim Highsmith coined Iteration 0 as a term in his Agile Project Management book. It’s defined as a first/early set of iterations that are focused more towards getting ready to begin building a product than on the actual construction. A wide variety of work can be encompassed in a Sprint #0 including, architectural definition, requirement analysis and backlog preparation, design work, setting up office space and building the team, training, project chartering, group planning activities, etc. The caution is not to allow your Iteration/Sprint #0 to extend too long.
• Blitz Planning. Alistair Cockburn defines Blitz Planning as part of his Crystal agile methodology. Crystal hasn’t achieved much popularity, so you probably haven’t heard much about it. However, there are techniques within Crystal that are quite powerful and this is one of them. In Blitz Planning you engage the entire team and key stakeholders in defining the overall plan of attack for the project. This includes developing the overall feature set, work tasks, dependencies, identifying key milestones, and such. At the end of a day or more of collaborative planning, you end up with a detailed, end-to-end mapping of the work. This includes when and how you’ll be doing analysis and design in order to effectively drive your agile iterations during construction.
• Story Mapping. Jeff Patton is one of the champions of this technique and is actively refining it. What often happens in agile product backlogs is that the individual stories often obscure the big picture and overall direction a product is taking. Story mapping strives to connect individual stories into the themes and feature interactions that your real customers will be using. Typically, it’s a low-fidelity technique where story 3×5 cards on a way are elaborated and refined from the customer workflow and user interaction points of view. It often identifies gaps and helps to prioritize what should be implemented in what order.

For those of you who thought that agile did little in setting the stage in advance of the work, I hope this post and the tools open your eyes to a different perspective. While the agile methods do take a lean, iterative view towards software construction, many projects need some initial vision setting. I also think these techniques can be mapped, to good effect, to the more mainstream methodologies. Happy exploring!

Don’t forget to leave your comments below

Robert ‘Bob’ Galen is the President and Principal Consultant of RGCG, L.L.C. Bob has held director, manager and contributor level positions in both software development and quality assurance organizations. He has over 25 years of experience working across a wide variety of software technology and product domains. Bob can be reached at [email protected].

For the past several posts, I’ve been focusing on user stories within the context of agile teams-how to write them and the role they play in agile development. This month I wanted to switch gears a bit and talk about the role of the BA within agile teams.

The first point I really want to make is not BA role specific but focused towards the general role of the agile team member. You see roles need to become much less clear or constrained within agile teams. Sure, a developer is still a technical role and will be mostly writing code, but that doesn’t mean it’s the only thing they can and should be contributing to the team.

There’s quite a debate in the agile community about generalists vs. specialists as team members. Clearly the more general you are, for example a tester who can write or read code or a BA who can test, the more flexible your contributions are within the agile team.

The pushback within the community is based on folks taking this idea to its (unintended) extreme, for example developers who believe we’re asking them to morph into full-time testers or vice versa. So, in general, pun intended, you should not view yourself narrowly as a business analyst, but more broadly as a team member who has strong requirement analysis skills against an even broader back-drop of capabilities that you often bring to bear within your team.

So, what specifically is the BA role within agility?

It starts out the same as it does in your existing role. You are a customer advocate and liaison. You have tremendous experience in the analysis and capture of critical system requirements. You have broad collaborative and observational skills. Often, you sit down with a wide variety customers, stakeholders, and constituents and gather and define requirements from a wide variety of angles.

But within agility there is so much more you can do along the lines of the following:

• Product Backlog Partner. Clearly the BA role focuses on requirement definition & refinement. Using Scrum as our terminology backdrop, it implies working closely with your product owner, customers, and team members to construct and refine the backlog. Remember, in the agile methods all work should be defined on the backlog, so it’s not simply feature-based. You need to be comfortable defining user stories that represent task work as well.
• Fostering Team Collaboration. BAs often become a liaison between the product owner (customer) and the team. They foster an inclusive view that brings team members together to better design and build customer-focused solutions. The methods sort of oversell collaboration as a natural occurrence. I have the view that it needs to be encouraged and often championed. BAs can clearly serve as this champion of collaboration amongst team members. I’ve often seen BAs adopt a facilitative role within their teams, facilitating effective meetings, information sharing, and problem solving.
• Driving Quality. Working with your product owner and testers, you help to define, refine, and even execute user story-centric acceptance tests. Often, you’ll view the execution of features from a more holistic, end-to-end usability view that is so important to the customer. Verifying that the software is as simple as possible while still meeting the customer’s usability and core expectations.
• Maintaining a Value Focus. Taking a page from Lean Thinking, the agile methods are extremely value and cost centric. Often you’ll see Scrum teams that focus not only on priority to determine what is worked on first, but they also try and determine the value (ROI) for a given feature set. BAs can often help facilitate this value-based analysis between team and customer. They can also help guide the team towards Minimal Marketable Feature sets (MMFs) that implement predetermined value, delivering early and often.
• Demonstrating Results. As a full-time member of your agile team, your true focus is towards delivering small slices of end-to-end functionality at the end of each sprint. Be willing to serve as a voice of your team in these demonstrations. Truly understand how the delivered software works and how to effectively demonstrate its value. Don’t be afraid to step into the limelight and demonstrate working code as part of each sprint review.

Often I think of the US Army recruitment commercial, “Be All You Can Be”, when I think of roles with agile teams. As an Agile BA, you should grow your skills horizontally and fearlessly contribute wherever you can within the team. Your teams and customers will value you for it!

Don’t forget to leave your comments below

Robert ‘Bob’ Galen is the President and Principal Consultant of RGCG, L.L.C. Bob has held director, manager and contributor level positions in both software development and quality assurance organizations. He has over 25 years of experience working across a wide variety of software technology and product domains. Bob can be reached at [email protected].

One of the larger misconceptions associated with user stories is that they are static; defined once and then never touched again. Another misconception is that they stand-alone as a requirement artifact. Another is that only a customer surrogate or product owner can write them. And finally, many miss the power of the acceptance tests as a clarifying vehicle for the story.

Over my next two posts, I want to address each of these in turn. Not only should these approaches help your user story writing, but your general requirements definition clarity and understanding should improve as well. And these misconceptions also assist distributed, non-local teams in eliciting stories that are more meaningful where they struggle to maintain active face-to-face communication.

User Stories are Organic!

If you study Scrum and product backlogs at all, you’ll realize that the backlog list of user stories evolves quite dynamically over time. Usually stories are created in a Story Writing Workshop at the beginning of a project effort. In this case the stories are often ill-defined and quite large-epics or even larger.

Coming out of the workshop, there is a tremendous amount of work to do on refining the stories, but certainly not all at once. The metaphor to keep in the back of your mind is – Tip of the Iceberg! You only need to refine the stories that are 1-2-3 or so iterations (Sprints) away from actual execution.

As you move forward, delivering those pre-defined stories, you actively groom the stories moving up on the backlog-getting them prepared for execution. Typically teams groom their product backlogs weekly. The process serves to refine the clarity surrounding each story. Often it will lead to other stories-breaking them into more meaningful units and discussing dependencies. Themes or packages of stories will emerge as well, as the product owner and team think about how best to couple stories into meaningful chunks for delivery.

The last and probably most important part of the dynamic is that the team factors in ongoing progress (execution velocity) and learning into their grooming.

While working with remote or distributed agile teams, it’s important to participate in these grooming sessions as a team. In this way, everyone is involved in the real-time conversations that are naturally part of backlog evolution.

User Stories are not a Catch-All Artifact!

The key driver for the content of requirements within agile team is the team itself. Let’s say a team member encounters a user story in a backlog grooming session that is simply too ill-defined to understand or estimate. However, they do understand the story well enough to suggest that-if they had a use case with it, one that was designed like one they’ve used/encountered before, they would have sufficient clarity to proceed.

In this case, they’re suggesting supplementing the Story with a known additional artifact form.

This is great!

Instead of trying to embellish the story as-is, simply link it to the newly created use case. In fact, it’s perfectly acceptable to link stories to all sorts of well known or used artifacts in your organization – traditional requirement (SRS) specifications, forms or templates, traditional use cases, agile use cases, wireframes, etc. All can effectively come into play to enhance and supplement your understanding of individual stories.

The caveat is that you don’t want to do this for every story. Let the individual cases or needs emerge from the team! Don’t create them too far in advance and certainly don’t create all user stories with the same level of detail. These extensions must come as requests from the team, i.e., they’re pulled as needed-preferably right before the implementation in the next iteration (sprint). Thus maintaining the just-enough and just-in-time nature of your story evolution.

One of the benefits of this approach is within distributed teams. These situations typically need richer documentation density with their requirements and this approach certainly provides it, while still maintaining an agile requirements approach.

As a final note, Alistair Cockburn has spent some time establishing the notion of Agile Use Cases. More information can be gleaned here on that topic – http://alistair.cockburn.us/Agile+Use+Cases

Next post, well finish with the other two misconceptions

Don’t forget to leave your comments below

Robert Bob’ Galen is the President and Principal Consultant of RGCG, L.L.C. Bob has held director, manager and contributor level positions in both software development and quality assurance organizations. He has over 25 years of experience working across a wide variety of software technology and product domains. Bob can be reached at [email protected].