Quality assurance analysts/Tester(s) in the agile team should still do some decent test planning.
Just like the analysts have to do research and planning before their user stories are placed in the product backlog.
Or just like developers, who also have to plan i.e. define and structure atomic tasks (tasks that will take no longer than 16 hrs to complete) for each and every user story.
Keep in mind that Agile requires a lot of planning. Unlike what you will hear from some non-agilists!! We plan however for shorter periods and that is why agile planning is more accurate and also why it works, if implemented correctly.

So, scripting your test cases should therefore still occur. This does not have to be at the granular level.
The danger here is that if the tester leaves the company, the new resource will have to rely heavily on the sprint team (analysts and dev) to get him/her up to speed. But that is true for any role in the agile team. As there are no longer 500 pages detailed requirements documents or design documents in the agile world.

Identifying the test cases and creating the scripts should occur during what my organization calls the sprint planning phase (when the user stories are being chosen by the team for the upcoming sprint). Sprint planning occurs in our approach, 1 week before the actual sprint (work) will start.

Because the number of stories that gets attacked during a 2 weeks or 3 weeks sprint is limited ( the number varies, based on complexity of the stories), QA gets ample time to do functionality testing ( system testing) and integration testing ( if need be).

Regression testing is a different beast. We recommend our clients to schedule a few days after code freeze for the last sprint (say sprint 7), to get everybody onboard to do a full blown integration and regression testing for the whole application.
If you have a great business customer, they can then install the app in their environment and fire away the UAT phase.

So all the testing types, still will get done. But in a smarter, agile way.

In short, when an organization adopts agility, everybody gets nervous. To have a successful implementation, a lot of common sense needs to be used. That means adapt agile, and make it work for your organization, but beware not to fall back to the waterfall methods. Realize that there is no pre-packaged approach to agile that will fit every organization (just like waterfall is different in every organization).

I have seen that time after time again as a consultant. I have seen companies that got frustrated after adopting agile, and … reverted to their old ways of developing software.

Cheers!

The following is the approach we take at Plannow Technologies when it comes to release planning. (I assume that the project is bound by a deadline, imposed by the customer, and that the Product Owner drives the release planning)

The release planning activities are:

-          Ascertain when the product must be delivered

-          Establish what high level feature areas you need to deliver

-          Prioritize the feature areas

-          Lists and prioritize the stories for these feature areas( you may have only epics at this time)

-          Provide rough estimates for the  stories ( story points)

-          Decide on the length of your team’s iteration for this project (some teams have fixed  iteration lengths for any project)

-          Use the team’s velocity to determine how many iterations you need based on the delivery date of the project 

        Example: If velocity is 20, and you have 400 story points (and the iteration length is 2-weeks), you will need  400/20= 20, two-weeks iterations to get everything done.  If you release every 8 weeks, you will need 40/8 is equal to 5 releases to get all features completed. 

-       Assign user stories to the  20 iterations based on the established priority of features/stories

Regarding which story goes into which individual iteration, I must acknowledge that such endeavour is never exact.  The first issue is that at this juncture you typically don’t have enough detailed user stories for the features you wish to develop.  The exact details should be deferred to the iteration planning meeting.  The second issue is that feature prioritization may change. A release plan should  in my opinion serve as a high level guidance that should keep the team and stakeholders  informed regarding what features  may be deliver and by when. If they cannot deliver all the features, by the deadline, the team (plus customer) should determine well in advanced, which features to drop, so that the date can be made. That’s the beauty of being agile.

Also, the Product Owner needs a lot of information in order to be able to create the initial release plan. Before we create a release plan, Product Owners typically have extended preparatory meetings/conversation with the customer.

Finally, a release plan will most certainly change. It is a work in progress.

Cheers!

During my initial years using agile methods, I was confused myself, as I tried to write every requirement (functional or non-functional) in the format: “As a <type of user>, I want <some goal> so that <some reason>.”

It took some practice/experience to realize that non functional requirement cannot be capture using the format provided above.

Largely , because non-functional requirements are not user induced.  

If you force yourself to write a non functional requirement in the “As a <type of user>, I want <some goal> so that <some reason>” format, you will soon realize that the behaviour that the system must exhibit , will be clouded, by a very convoluted user story statement.  

Take for example the following non-functional requirement, written according to the IEEE standard (If I am correct): “The payment system shall use a 256 bit encryption”.

This is a requirement that is not specific to a user. If you force yourself to put it in a user story format, it could look like: “ As a System Admin, I want the payment system to use a 256 bit encryption sothat…..”

That may look right at first glance, but, if you analyse it properly, you soon will realize that the statement is incorrect. The encryption requirement is not induced, or initiated by the System Admin or any other user for that matter.

It is a system-wide requirement. That is why it is a non-functional requirement. This is the same type of requirement as: “The application shall only run on windows 2008”.

My experience with working with non-functional requirements and architectural requirements has thought me to be very careful. If, after talking to stakeholders, studying and analyzing the business processes of an organization, you cannot find, or couple an actor, or persona to a specific requirement, be very careful about how you document that requirement.

I recommend my teams to write those types of requirements using the IEEE standard and place them in the product backlog for prioritization and eventually size estimation. Typically, you will have very few non-functional requirements in a project. So don’t worry too much.

It is important to realize that no matter how you choose to write your requirements, your duty as a Business Analyst or Product Owner is to present 1 or 2 line statements of what behaviour the system must exhibit, to the sprint team. During the planning meetings the team will discuss the requirements, (functional, and non functional) and estimate them using story points.

In the second phase of the planning meeting, tasks will be created for every requirement, and the level of efforts (duration in hours) will be estimated by developers.

 Cheers!

The company had several software development teams in various locations in North America and wanted every team to drop their waterfall habits and move to agile.

I will be the last one to say that change is not a scary thing. Especially process changes. What I noticed in that organization is that most of the big players in the project management and product management departments were very reluctant to go agile. Business analysts and project managers where whispering in the hallways, saying they would better leave the organization, because there is almost nothing left that they can control. They argued that they don’t control the requirements collection and prioritization process any longer, as the “Team” is now responsible for that.

Project managers complained that they have become scribes and cannot plan and manage project activities as they used to while following the waterfall process.

One very important thing they did not fully understand at that time is that agile methods ( Scrum) requires a lot of planning, in order to be successful. Activities such as backlog planning, backlog prioritization, sprint planning and tasks planning demands a lot of attention and time from analysts and project managers. At least if the project is to succeed.

Business analysts will always be needed to collect the initial requirements that fuel the product owners ‘ product backlog. There is no way around that for especially enterprise wide applications. Unless the company has a pool of developers that are extremely knowledgeable of the business domain, and are capable of extracting requirements and defining business rules.

Cheers!

When identifying granular tasks for this particular story, one design task could be, “Create UI (to allow Admin to add new users)”

A database task for this story could be, “create table (data model)”.

You see the trend??

After identifying all the tasks that are needed to materialize user story #1, the team will do the same for user story # 2, user story # 3 , etc. At the end of the sprint planning meeting you will have a task board, which can have close to 80 tasks or more (depends on the complexity of the stories of course) for all the identified user stories.

Now to answer the question directly; the User Interface Designer will choose one of the design tasks from the task board, complete it, and report the status in the daily stand up meetings.
Developers, then can pick up a programming task from the sprint backlog, which depends on completion of the UI task.

After the first UI design task is done, the next task is taken from the task board, by the Designer. Developers start working on the recently completed UI, and this cycle is repeated until all outstanding UI design tasks are completed. Step by step.

Keep in mind, however, that if this is a completely new project, you may want to consider having a sprint 0 to establish architectural base line and other foundational things.

I did not address dependencies here in-depth. But it suffices to say that during sprint planning meetings, and subsequent daily stand-ups, the development team will figure out the dependencies between tasks, and stories. That will determine which tasks will be completed first.
After all, we use a lot of common sense in agility. It is only sensible to complete a task, upon which another task depends, first.

Cheers!

If you agree with me that some discovery work needs to be done before any project can be properly planned and started, than read on, because all the information you need to create this detailed release plan can be captured in one, two hours (initial discovery meeting) with the customer.

User stories, the foundation of the release plan
A key requirement for creating a product release plan is that the initial requirements collection (discovery) session must have been conducted already. This requirements collection meeting will provide the foundational material to create a release plan.

Please realize that the feature areas (themes), epics and many of the stories identified in this initial session will still be high level. No detailed requirement such as business rules, data elements will or should be collected at this juncture. Leave that for just before the first iteration is about to start. To create the initial release plan (using the basic information from the initial discovery session), you therefore must employ deduction and estimation techniques, as well as your domain and software engineering knowledge. Once again, it will not be perfect, but this plan will be extremely useful for the development team and the rest of the organization (resource planning, marketing).

Why a release plan is needed, long before development work starts
We all know that when a project is identified by the business (in moderate size organizations or larger), no Scrum team has been formed yet to work on it, and that we therefore simply don’t know who will work on the project.
Companies, typically, have several projects on their overall product roadmap. All these projects need a detailed release plan, and proper resource planning must be conducted to know which resources will be assigned to work on these various projects. Release and resource planning therefore take place weeks or months before the actual development work starts.
The various release plans assist Product Management and Development Management in significant ways, long before a Scrum team starts to  actually work on the project.

In essence, a release plan being a Product Management tool is not something the development team needs to see or worry about. The development team works with the prioritized product backlog. A reasonable release plan will facilitate the creation of the prioritized product backlog.

What do you need in order to create a reasonable release plan?

• The initial themes, epics and stories
• The delivery date of the product (when the customer wants it)
• The established length of the iterations in your company (if iteration lengths fluctuate, choose a length and convince the future Scrum team that will work on the project to adopt it)
• The average velocity of Scrum teams in your organization (choose the velocity of teams that work in iterations cycle with the same iteration length as you choose for this project)

If you have all the above variables, you will be able to create a reasonable release plan. Once more, please be cognisant that product release plans are very high level plans. We must realize that this plan will certainly change.

However, refrain from changing a release date agreed on with the customer or a release date imposed on you based on your domain of operations. For example, a Student Management System may need to be released by April 30th, because schools are getting ready to process transcripts, and need the product to be ready.

There is no way the software team can delay the release date, in this case. If for some reason the team is in danger of not meeting the release date, the Product Owner must negotiate with the customer to remove certain stories from the current release and schedule those stories for a subsequent release.

Dangers of Not Having a Release Plan
The dangers of not having a product release plan are in my opinion:

• Not knowing which features areas or features to build first

If no time is spent identifying the feature areas that have more value for the customer, we may focus on the areas that the customer may not want.
Why spending time building something that the customer may reject?

• Not knowing when the product must be released exactly

If no time was spend identifying when the customer wants the software to be operational, the project will quickly become a low priority project and no resources will be assigned to it. Or on the other hand, the team will start working without really having a sense of urgency. No fixed release date, means no time box.

• Not knowing when development should really start (because you don’t know when the product must be deliver)
• Not knowing when resources should be made available for the project, because we don’t know when we must start in order to hit the deadline.

Who creates the release plan?
The Product Owner must be the one to create and groom the release plan. Product Owner must ensure a knowledgeable development lead ( if dev team was not yet officially formed or available) is present while creating and reviewing the release plan.

I have seen many successful implementations of release plans in several organizations. Being structured and organized always helps. Main stream Agile is now ten years old and we have learnt a lot in the last decade. Remember the time when some Agilist were advising you wrongly not to create any documentation at all. Similar to that, you will have many Agilist tell you not to create release plans.

My advice is simple. If you have a small organization, with just a handful of teams, you probably could survive without a detailed release plan. If you have more than a handful of teams, then you should seriously consider proper release planning.

One very important aspect is missing however.  There are many analysts out there that are experts in defining functional requirements through use cases. And since user stories are in fact a representation of the functionality that the system must render, why not look for areas where the two can complement each other. 

 A few years ago I worked for a company that was in the process of moving from traditional methods to agile methods. They wrote requirements using two different styles, and now had to look for ways to do so the agile fashion. Here is an example of how I solved the use case/user story dilemma back then.

Let’s take a simple example. Assume that the business need is: Providing a System Administrator the ability to configure system lock out settings.

Business analysts in that company were writing the functional requirements in two different ways as alluded to earlier:

* Analyst 1 (using shall statements): “The System administrator shall be able to specify the number of unsuccessful log on attempts before the system locks the user account”

* Analyst 2 (using use cases): “Specify the number of unsuccessful logon attempts”

In the subsequent use case narratives ( use case scenarios), Analyst 2 would specify in great detail the dialog that would take place between the actor and system.

Nothing is wrong with the two approaches in essence. You would certainly understand what the real requirement  was when reading the two statements. Analyst 2 however, unwittingly, wanders into design while detailing the interaction between actor and system.  And that is exactly where use case writers will get into contention with agile practitioners. Some of my agile coaches in the past argued that use cases should not be used at all.  I disagree respectfully.  As use cases and user stories are in essence a verbalization of the requirements from the point of view of the actor or user, I argued and proved that they can be used to populate an agile product backlog.  In the example I just provided, I recommended my client (and they really wanted to move to agile methods), to write atomic use cases, but to refrain from detailing the interaction between the actor and the system.  That is the caveat.

It effectively means, just stick with the “title of the use case”. But write the use case title properly, so that the goal to be achieved is clear, unambiguous and testable (I will spare you further details here).

An atomic use case such as “Specify the number of unsuccessful logon attempts” can easily be converted into a user story if need be.

The user story could look like:
‘As a System Administrator, I want to be able to “Specify the number of unsuccessful logon attempts” before the system locks the user account, so that I can minimize the risk of unauthorized access ‘.

A functional requirement with an identifiable actor can easily be transformed into a use case, or a user story.  There is a close relationship between traditional requirements, use cases and user stories. The transition to user stories can easily be mastered with minimal training.

Where you would run into trouble, is when you need to document requirements that don’t have a user interface component, such as low level architectural requirements and some non-functional requirements.

So to conclude, place only the descriptive title of the use case in your product backlog. Don’t put the dialog between actor and system in the product backlog. If you have a backlog with say 500 one-line use cases (or user stories), that would already be a nightmare to manage.

Cheers!

The reasons while Agile fails to come to fruition in many companies may depend on  a variety of factors.  One of these factors is how Agile was introduced to the organization.

In this post, though, I’ll briefly talk about how Agile can be introduced, without focusing on whether one approach is better than the other.

Approaches

• Simultaneous approach (All teams at a time)
• Exploratory approach (One team at a time)

Simultaneous Approach

Some organizations train everybody in the software development teams and set a date to transition from whatever method they were using prior, to Agile.

Since everybody is trained and speaks the same “language”, teams can go ahead try it out, make mistakes and learn from the mistakes. Inspect and adapt is key here. After every iteration the teams should individually inspect their practices and adjust those to make them operate better.

The simultaneous approach is very good for organizations that are truly sold on Agile and where everybody feels involved. Initially there will be some chaos and some frustration. But with an Agile champion in senior management, rest assured that after three –to – four sprints,  all teams should be now so familiar with the Agile way of building software, that they would not want to go back.

The key thing to watch out for is that when people get frustrated, management is there to assist and guide them. That is why senior management buy-in is so crucial to the success of  the simultaneous approach. More so, because for approximately two months productivity will nosedive, while the teams are learning the ins and outs of being Agile.

Exploratory Approach

Other organizations prefer the slow exploratory approach to introducing agility to their organization. They will choose a team, train that team in Agile principles and practices and let that team  be the “guinea pig” . While this single team is trying out agility the rest is plowing ahead according to their established processes.

After three-to-four iterations, the exploratory team should have gained enough experience in how to make Agile work. The next step in the process is that other teams will switch to Agile. Now these teams don’t have to start from scratch. They can learn from the experiences of the exploratory team. A good idea is to allow a team member from the exploratory group to be part of a new team so that they have an “experienced” person in their middle.

This approach has been adopted very successfully by many cautious organizations. The disadvantage of introducing agility this fashion is that it will take a while before the whole organization is onboard. Productivity will still take a nosedive, but now the nosedive will occur in waves and not all at once.

I have no special recommendation which approach to choose. It all depends on the management of each individual organization. Do they want a dramatic, quick transition, or do they want a slow and gradual transition.

Both ways work just fine. As long as senior management wants to go Agile.

Take for example the way requirements are specified or documented in the Waterfall methods.

Many organizations capture requirements through use cases. However, if you study the way they structure their use cases, you will seldom find two organizations with identical practices. The use case templates created to structure the way the use cases are written by business analysts vary so much that it often takes time for newly hired analysts to get accustomed to the ways the new organization works.

When you move to the Agile world (and we’ll use Scrum in this example) many people have the impression that there is only one way to do it right.  First of all, Scrum is a project management framework and not a process. That means it provides just guidelines and is not prescriptive. In other words, it does not tell you exactly how you should collect and document requirements, how to conduct design, how to implement the design and how to test.

But yet, time after time you will meet individuals who will tell others that they don’t collect requirements (user stories) in the right way. Or that the design is not conducted in an agile fashion.

But what is the agile way of creating a functional design? In some organizations the design is conducted collaboratively and incrementally on a whiteboard during the sprint. In other organizations the design is created incrementally using a design tool and presented to the team during the sprint planning for review, critique and eventually improvement if the team decides so. Which of the two approaches is better, if at the end of the sprint the team produces a product that satisfies the needs of the customer?

That is hard to answer, but you have so called Scrum gurus that will tell you that you are wrong, if you don’t design software the way they know works for them.

Another very hot issue is the notion of whether a Product Owner should participate in the Scrum Retrospect. In some organizations, the whole team from product owners, developers to technical writers will participate to evaluate their past sprint and come up with ways to improve their process. This is one of the core agile principles. Inspect and adapt.

You’ll also find organizations where the Product Owner is banned from participating in the Retrospect.

That is fine, as long as it works for them. What is not fine is to tell organizations that follow the first approach that they are not adhering to Scrum because the Product Owner is partaking in the Retrospect.

It is usually very clear when an organization is practicing Scrum or not. However, bickering about minor implementation details is a useless endeavour. You will never be able to get every organization to implement Agile/Scrum in exactly the same fashion everywhere. We are all inventive and different.

If we succeed to build the “right” product iteratively and incrementally in a speedy way, then we are on the right track. Keep in mind that the signatories of the Agile Manifesto did not agree on every little detail of how to be agile.

The Stories Overview Page is a grid consisting of relevant attributes that a decent user story should have, including the Story ID, Name, Description, Type, Priority, Rank, Parent Epic, Parent Theme, Iteration, etc. We also provide an action feature per story which contains commands such as:

• View Story Details
• Edit Story
• Close Story
• Move Story
• Block Story
• Follow Story
• Assign Story
• Add Task
• Delete Story

Each one of the above listed action will initiate an event or operation on the selected story. Some events will navigate you to a different page, while others will merely change the status of the story.

Sorting stories can be accomplished in several ways. For example, the sort column (up-down arrow icons) will allow the user to move rows up and down.  This is effectively ranking the stories.

A great feature is that once you are in the Stories Overview Page of the default project, you can easily navigate to the Stories Overview Page of a different project, without the need to go to a different page.  You can also filter the project by iteration. If you have 10 iterations for example, you can simply select the iteration of interest and the stories associated to that iteration will be displayed in the grid.

Filtering by status is also possible.  Almost every column heading can be clicked to sort the grid. Clicking the Type column heading will sort all stories by type. Clicking the Epic column heading will sort all stories by epic.

There are many other handy features available on the Stories Overview Page. As we slowly progress, we will reveal more features as well as other screenshots of the product.  
Stay tuned!

Cheers!