Those skeptic people are quick to get offended when I say that Software Engineering is not Computer Science. They take pride in citing Frederick Taylor’s “scientific management.”

And maybe that’s the problem: The traditional project management approach was tagged as “scientific”, so anything else that is not traditional project management is not “scientific”. This argument is not only a Denying the Antecedent fallacy, but also it’s a clear disregard of the fact that the empiricism (the foundation of Agile) is a cornerstone of the scientific method.

So these are the arguments I heard from them:

• “The absence of up front planning in Scrum gives to much freedom to the customer”
• “Given that the client can change anything in the backlog, you can’t take any stable architectural decisions”.

Why this is not a problem?

1. Vision must to be clear up front. We are going to build an account system or a social network? What is the value obtained with this project?
2. Agile does Planning. Agile does just enough up planning in order to have User Stories. The team should have enough User Stories to make a Release Agile Planning where costs of user stories are given based in complexity and dependencies between them. Afterwards, long enough architectural and design discussions take place before starting the first Sprint.
3. Through the iterations, Adaptive planning is performed while the team takes advantage of the flexible architecture that was chosen.
4. The most valuable User Stories are delivered first, each User Story represent an End-to-End functionality that traverses all the architecture required by the system, that is what is called a Walking Skeleton. So the team has a clear vision of architectural requirements from the beginning. That vision is clearer as the User Stories are consumed.
5. An important rule to remember is: The Customer can change anything in the backlog as long as he/she stays within the constraints of the Iron Triangle [Update: I better use "Agile Constrained Triangle", A concept I just made up to depict a Triangle where the constraint of Scope is flexible, but Time and Cost are not]. That is, the client can delete User Stories or replace cost-equivalent User Stories. If client wants a User Story that can’t be implemented with the tools, design and architecture, that means that the vision wasn’t clear at the beginning of the project. Please observe that more up front planned user stories would have not avoided this problem. This is not a problem of lack of depth, it’s lack of breadth. Up front planning deals, by definition with, greater depth. What I’m saying is that the same problem would have happened using any kind of project management. On the other hand, if the User Story the customer wants is more expensive than the one being replaced, it is also breaking the cost constrain, but in a lesser way. So that’s why I recommend flexible contracts with scheduled buffers to handle those minor changes in cost.

People who looked at this item also looked at…

• Six Practices to deal with assumptions, risks and priorities
• Agile is about Reality not Fairy Tales
• Why do we estimate?
• No agile practices or processes are substitutes for a Roadmap or Vision
• Attaching Business Value to User Stories

Related items

• Scrum Release Planning
• Six Practices to deal with assumptions, risks and priorities
• Attaching Business Value to User Stories
• Coping with Quality Assurance Issues
• Stop being in pain

By the way, remember that the Product Owner role is a subset of the Product Manager. That is, the Product Manager is the best fit for being the Product Owner.

That said, what you are going to see in ScrumMaster trainings are the practices and values the ScrumMaster has to monitor thought the Sprints. I had the luck to have a short discussion about the Agile Release Planning during my training three years ago, but as far as I know that was an extra.

I hihgly recommend therefore this couple of posts about agile release planning:

Release Planning

Agile Release Planning

“Maximizing Value with Agile Release Planning” Recording

People who looked at this item also looked at…

• Coping with Quality Assurance Issues
• Agile is about Reality not Fairy Tales
• Six Practices to deal with assumptions, risks and priorities
• The wisdom of knowing when to use Agile
• Why do we estimate?

Related items

• Six Practices to deal with assumptions, risks and priorities
• Coping with Quality Assurance Issues
• Predictive Planning vs Adaptive Planning
• Attaching Business Value to User Stories
• Stop being in pain

Failure appears when something you assumed proved to be false. That’s the time to review our axioms, with the honest willingness to change them if necessary.

For a Product Management perspective, the longer you wait to realize an assumption is false, the more expensive it is to change what you built over that assumption.

The “cost of changing what was built” as time passes and the probability of the happening that in fact it was a bad assumption is what I understand as risk.

Here my six practices to embrace and live comfortably with assumptions, risks and priorities:

1. Associate a risk numeric value to each assumption.
2. Associate a risk description and the correspondent assumption to each User Story.
3. Before starting the product development, be sure to have cleared all the higher market, platform, technology risks.
   • Refine your persona.
   • Talk A LOT with users fitting your persona.
   • Continue refining your persona in the process of talking.
   • Review market penetration of the platform and technology used by your product.
   • Review market trends.
   • Review the Business Strategy of your company.
4. Star developing those User Stories with higher Business Value and those with the higher risk associated. Answer the tougher questions first.
5. Pay consulting services to a Subject Matter Expert to review the iterations increments. This is a review process independent, not related to the Team Review Meeting. Remember the team presents the increments to the Product Owner, not to the SME, at least of course the PO is the SME.
6. Start a customer base, even when you have only the concept of the product.

Further Reading

Brutal Prioritization in Agile: cut costs by NOT building the fluff

People who looked at this item also looked at…

• Why do we estimate?
• Predictive Planning vs Adaptive Planning
• Agile is about Reality not Fairy Tales
• Coping with Quality Assurance Issues
• The wisdom of knowing when to use Agile

Related items

• Scrum Release Planning
• Predictive Planning vs Adaptive Planning
• Attaching Business Value to User Stories
• Stop being in pain
• The task board shows WHAT and HOW we are doing during a sprint

Maximizing work not done is the art of our trade. The business value of a story is looked into precisely for this reason. If you don’t have a good reason business value) behind a given piece of functionality (story), you are wasting time by working on it.

Brilliant.  I can’t add more but this few words: If you are building products maybe finding the Business Value for a User Story is hard, really hard. But if you can’t find one, you loose credibility of the team. The team will have the feeling that you are making up the value of the feature. So talk with customers, talk with them a lot, talk with many of them in order to find how much the story is worth with respect the total price they will pay for each copy, and then project the revenue this story will have, given how much copies you are going to realistically sell. That will be just an estimate, but a very educated one.

Further reading

Why do we estimate?

People who looked at this item also looked at…

• Why do we estimate?
• Six Practices to deal with assumptions, risks and priorities
• No agile practices or processes are substitutes for a Roadmap or Vision
• Agile is about Reality not Fairy Tales
• Coping with Quality Assurance Issues

Related items

• Predictive Planning vs Adaptive Planning
• Scrum Release Planning
• Six Practices to deal with assumptions, risks and priorities
• Guest Article by Gareth Powell: Why do we estimate?
• The task board shows WHAT and HOW we are doing during a sprint

A very engaging aspect of Scrum (and Agile in general) is to find innovative ways for solving problems found in the Retrospective meetings. By the way, the Retrospectives are are rich well of requests and improvement opportunities. By pandering to those requests (and inspecting at the solutions) you will get a tailored improvement to the process.

How do we at Artinsoft do for keeping track of our Sprint progress using the Task Board? Let me explaining it to you by telling you the story.

We have acknowledged that the following phases are needed in order to set a done criteria for the User Stories we committed:

• Design: Meetings to discusses architectural issues,
• Development: Coding
• Application Quality Improvement: Pair Programming and/or Code Review. We prefer Pair Programming.
• Testing: Quality Assurance in the way of Developer or Integration Tests
• Usability Tests

Additionally, a sixth kind of tasks emerged: Environment, as a mean to say that it is a task that encompasses all the environment setup (technology setup) to accomplish the User Story.

Well, in one Retrospective long time ago we pointed out that some User Stories were lacking of enough quality. Why? …. Got it! one or more aforementioned phases were being skipped when planning and implementing features. Why? We EASILY forget to get sure we get them while planning and even implementing. At the second level of “Why?” we realized we needed something catchy to remember those phases and to avoid the constant tendency of realizing them when the deadline is looming, or even worse: never!

We devised a solution: Use a specific color for each kind of task when doing the Sprint Planning and do a Color Distribution Assessment constantly: Do we have enough of all colors for all User Stories? If not, is there a unanimous and intentional awareness of it?

Our Taskboard looks like this:

We always have a good supply of sticky notes next to the TaskBoard, one color stack per phase or kind.

Along the Sticky notes we also have a supply of red round labels. Why so?

In the diagram, I pictured an hypothetical second day of the Sprint, in the Stand Up. The team member David (hence the “D” in the sticky note) delayed more than the recommended (and estimated) one day for that pink task (Usability) he committed to finished. He sticks a red round label to the task and in that way the Task Board is irradiating to the whole team that we are behind of the Sprint schedule.

Again, this has worked for us and fits to our specific circumstances. What do you think about it? Feel free to give me your opinions, all your comments are needed and welcomed!!

People who looked at this item also looked at…

• Why do we estimate?
• Getting even more serious about your meeting problem
• Six Practices to deal with assumptions, risks and priorities
• Attaching Business Value to User Stories
• Collaborative environments to achieve goals

Related items

• Scrum Release Planning
• Six Practices to deal with assumptions, risks and priorities
• Attaching Business Value to User Stories
• Collaborative environments to achieve goals
• Coping with Quality Assurance Issues

The more quality our delivered software has, the more fulfillment our purpose reaches. All the software we produced should be supposed to be used. We make it for our customers. Our customers are represented by the Product Owner, who is able to realize and prioritize the features (User Stories) that the end customer wants.

The software or product is made out of features. Sometimes the team forgets about the business value that every single task should have. Certainly, the explicitly stated business value is in the User Story. However, when it comes to take that User Story and disaggregating it into tasks, all the team is responsible for remembering how every single technical-level task is going to build the committed User Story. Every single task should be able to make (directly or indirectly) our Product Owner happy.

Each Sprint has a compass: The “sprint backlog” out of the Product Backlog. Every release has a compass: the Product Backlog out of the Roadmap. As you can see, each user story of the sprint is a glimpse of what our customer or Product Owner wants.

Iteration Zero
What about “Iteration Zero” ? By “Iteration or Sprint Zero” I mean that period of time when the team doesn’t feel able to deliver a “potentially shippable increment”. Before that, team needs to make some setup and “architectural” decisions.

In that special Sprint, many teams had found useful to make User Stories whose Product Owner is “The Team”. Even without the normal nature of the Product Owner and without the normal nature of User Stories, the Team needs to be focused. In those circumstances, the Acceptance Criteria are still extremely important as well as the Iteration Zero Review meeting. If not, you will find your team upset and lost. Without a clear goal (set by User Stories with Acceptance Criteria) it is highly probable get distracted and get developers implementing unnecessary stuff.

Once you start to deliver business value, that is, product features, you will find your team uplifted when they can see a satisfied Product Owner reviewing the completed User Stories of the Sprint. That experience is extraordinarily motivational and depends on the quality and completeness of what is delivered.

Before leaving I want to give you this quote from Mike Cohn’s book Stories Applied: For Agile Software Development

“A team is not allowed to deliver half of a feature. Similarly, a team is not allowed to deliver the full feature but at half the quality. By the end of each iteration the team is responsible for delivering working, tested code that can immediately be put to use.”

Related items

• Predictive Planning vs Adaptive Planning
• Scrum Release Planning
• Six Practices to deal with assumptions, risks and priorities
• Attaching Business Value to User Stories
• The task board shows WHAT and HOW we are doing during a sprint