Is this approach 'agile'? Separating use-cases into sprints/iterations

Question

This may be a weird question and please bear with me, I am completely new into this.

I have a list of 20 requirements (use cases) which I received from my client. With him, I prioritized this list of requirements (1 highest 3 lowest). I wrote for every requirement a use case scenario (rather than user story). I also have a use case diagram and some technical designs (class diagram, database diagram).

Now, my plan is to separate this list of 20 requirements into 5 sprints. Each sprint lasts one week. During every meeting with my client, I can show the product with 4 new use cases implemented. If one of them isn't finished, I move it to the next sprint and my client can request a change during this meeting. During this change, the specific use case diagram and classdiagram/database diagram may be changed.

Is this considered to be Agile? (Even though he gave me the full 20 requirements from the start of the project)

Answer 1

It's hard to say something is or is not Agile. It's a little easier to say something is or is not Scrum (this isn't, but I don't think you should get too hung up on that). It's often more beneficial to ask "How Agile is this?" There are a lot of great things you've got in there including prioritizing a backlog, rapid feedback loops, continual validation with the customer, and the ability to roll with changes. There are a few things that I think most Agile professionals have come to accept as key parts of Agile that you might want to consider moving toward in the future.

1) Separating What and How: User Stories are not a required part of many Agile practices. That said, almost everyone has moved to user stories because it describes the "What" to build, or the user need that has to be addressed, without dictating "How" to build it. Leaving the architecture and design in the team does a few key things. First, it leaves the door open to different solutions. A classic problem in waterfall approaches is that you establish the solution at the beginning of the project, where you've had no chance to validate your assumptions yet and, if it doesn't turn out to be the right solution, you have no good opportunity to change that. While you may be very technical, you aren't the one directly learning if the approach is working and have to rely on the people writing the program to give you feedback for you to update those diagrams. Second, the team isn't invested in the solution because it's your solution. If something doesn't really work in the design or some other factor means another design would be better, they still succeed by building your design, not by solving the problem the best way. If they determine the how, they own it and have a personal motivation to see it done right. If the team is not particularly experienced, consulting with a more experienced developer may be beneficial, but the solution should still be theirs.

2) While your schedule isn't set in stone, you are making assumptions about how long things will take and I don't see anything here about previous work from the team that suggests that the number of requirements per sprint is based off of anything other than what was asked for. I'm reading between the lines a bit here, but it feels like there may end up being some hidden pressure to "follow the plan" once things start going.

All that said, you'll probably get a lot of great benefit from the steps you're taking and there's always something else a team can do to improve or become more Agile, so don't be down on if what you're doing "is Agile." Just know that a key part of Agile is committing to continuous improvement.

Answer 2

Before answering your question, I want to make two comments:

• I am absolutely sure, that doesn't matter, can be your process called "agile" or not. The main goal of your development process to give to you and your customer maximum profit with minimum effort.

• If development process has iterations, this mean only that you use Iterative Development Model. Development process based on Iterative Development Model may be not agile, but agile process should use iterative development model.

And now answer to your question:

Looks like that your process adheres agile approach. But there are too many details, that you didn't describe.

In more details:

Agile postulates two main values:

• Flexibility in relationship with customer:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Do you have early and continuous delivery? Yes, you have iterations in your development process, but do you have realisable product after each one?

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Ok, you said, that customer can change unfinished features, but can he change requirements to functionality, that you are already implemented?

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Ok. You have an one week iterations. This principle passed =)

Business people and developers must work together daily throughout the project.

Ok. You have consultation with customer after each iterations. It is not "daily", of course, but by my opinion, it's enough. Passed.

• Flexibility within development process:

You didn't describe this aspect at all.

Answer 3

In extension to Daniel's answer: I guess an important aspect regarding to how agile are we is the view on the result.

You wrote, "the customer may change the use cases between the sprints". For sure, the customer will do this based on the results you achieved up to this point. This is also possible in waterfall projects, e.g. via change request. So it is not an absolute indicator for being agile.

But would you or customer accept that not all requirements might be realised? May be due to larger effort for the realisation of previous requirements or because it turns out that the realised requirements are enough to launch the product.

For me, this is an important part of the agile mindset from the view of the customer / contractor relationship. If this is not the case, you have to guarantee that all requirements are met and by this you might end up in classical PM and agile development.