Okay, great. Now I have Agile down pat.

Everything is now right with the world. (Well, some things at least.)

But wait a minute! Now I have a project that has barely any user interface at all!

And my product is some kind of fancy API that won't even have users!

Now, what am I supposed to do???

Never fear; we'll clear this all up in our upcoming Tutorial Tuesday.

As Business Analysts, our management, teams, and other stakeholders expect us to come up with reams of documentation.

And sometimes that's literal (ream = 500 pages).

But this isn't supposed to be an expectation in Agile, where we value working product over extensive documentation.

But sometimes that is an expectation -- and we have to deal with it one way or another.

In this Tutorial Tuesday, we will learn how to put this issue to rest, once and for all.

One of the great accelerators of Agile is not having to create documentation that doesn't provide value to stakeholders.

Really, you don't.

But that doesn't mean we never create documentation. Indeed, if some artifact is valuable, then yes, please, put it together.

In our upcoming Tutorial Tuesday, we'll cover what, when, and how to create use cases... the agile way...

Agile has taken over the world of software development...

Or has it?

It's extremely common for teams to adopt the terminology and surface processes of Agile, without embracing the fundamentals.

And the fundamentals produce all the true organizational benefits.

As Business Analysts, we have a great opportunity to socialize the agile mindset. In this Tutorial Tuesday, we'll look at how best to do precisely that.

Sometimes, our agile teams tell us that our stories are just too... darn... big. 

No problem; we'll just split them into more manageable and independently-deliverable pieces.

But this can be a real challenge on complex products with many moving parts...

And even more so when the story already seems so small.

In this Tutorial Tuesday, we'll cover how to tackle this problem once and for all.

"So, we need to get convert this document into user stories."

Words we never want to hear for the rest of our lives, for one thousand, Alex?

As unwelcome as the task may be, we need to do it...

But not in the way you think.

Join us for a quick and simple approach to turning that dusty old BRD into a sleek new product backlog.

Vendor projects (where another company is providing you with a pre-built solution) have immense business analysis needs.

But these needs are substantially different from the typical analyze-build-test approach we use in standard enterprise development.

If you understand the differences, you'll run the project right, position yourself as an expert, and save yourself a lot of frustration.

If you don't, you'll mess the project up, position yourself as a doofus, and be eternally frustrated.

In order to run the project right, you need to have a strategy for approaching this unique class of requirements efforts.

And that strategy is what we'll be covering in this Tutorial Tuesday.