Posts Tagged ‘“user stories”’


Sitting In A Teamroom Makes You As Agile As Sitting In A Garage Makes You A Chevy

July 8, 2013

You have a task board in your teamroom that you use to track the status of your users stories and tasks. But do you have any idea what is a reasonable number of tasks to have in work at any one time? The burndown chart that your tooling or your scrummaster makes is posted – isn’t it? Do you use it to understand the likelihood that your work for this sprint will be completed as planned? In every planning session you dutifully use Planning Poker for estimation. However, do you understand why using it is important and why this type of estimation actually works?

A professional mechanic understands more than just how to use the tools that are in the garage. The professional mechanic also understands how the tools work and why. It’s great that your team has learned many of the various agile techniques. But if you haven’t learned why those techniques work, you risk using them improperly, putting your success in jeopardy.

There is an old story about a young woman who is preparing her first holiday feast for the whole family, which included making a delicious glazed ham. She remembered, as a young girl, watching her mother cook. She called her mother to ask her why, when she cooked ham, she cut off the end of the ham before cooking. Her mother answered “Because my mother did it that way.” Now more curious, they called the grandmother and asked why she cut of the end of the ham before cooking. Grandmother told them it was because her mother did it that way. They were very fortunate that their Great-Grandmother was still around, so they called her and asked why she cut of the end of the ham before cooking. Great-Grandmother’s answer was simple…her roasting pan was too small.

Do you know “the whys” behind the agile techniques you do?
Improving Your Software Processes and Practices
Agile Adoption and Transformation


What Are You Sprinting Toward?

May 7, 2013

They knew all eyes would be watching them. They knew huge crowds would be in attendance. And they knew some of those attending were there to cause trouble. Facing this, the Tampa police had an interesting objective for the week of the Republican National Convention. You might expect an objective like “Keep the peace.” Or “Do what it takes to control the crowds.” Or some other stereotypical statement. But no. Their stated objective was that they did not want to see the police on the nightly news.

Quite an unusual objective than would be expected. It did restrict the police in some ways, but still allowed them to carry out their mission while keeping the department’s overall objective in mind. The results: The convention was peaceful, protesters had their say without violent crowds rampaging in the streets, and you didn’t see the police cast in a bad light on the nightly news, if you saw them at all.

Do your sprints have meaningful objectives? Or do you think that is not important?

Objectives keep the team focused on what is important; what you want to achieve overall vs. just delivering the stories in the sprint. They also help eliminate the unwanted results (e.g. seeing film of police in riot gear hosing down the crowds with water cannons).

Unfortunately, instead of thinking through a good objective for their sprints, many teams just work bottom up. They pick their sprint stories and just use a summary of those as the sprint objective(s). This approach is not effective. It boils down to “Do your job” as an objective. It provides no guidance at all as to “how” or with what considerations the work is to be done. For example, the police could have showed up in full riot gear, with water cannons in visible locations, lined up in high numbers around the protestors, with paddy wagons at the ready. But that would likely have guaranteed high visibility news footage, and not in a good light.

There is also a psychological side to having objectives. To reframe a well-known motivational story, what is more satisfying: “I laid ten rows of brick today” or “I finished a cathedral today”? Just finishing your task list for today is good but it rarely gets you energized for tomorrow. But finishing a customer objective (i.e. the cathedral)…now that is something else.

If you are doing sprints or releases without having meaningful objective(s) you are depriving yourself of a simple technique to keep the team focused on the outcome desired and cheating your team out of well-earned celebration of their achievements.

(


Fun With Frames and the User Experience Model

April 12, 2010

Development teams don’t necessarily receive “requirements” from their stakeholders as use cases, textual requirements, user stories, or even “drive-by requirements” (where the stakeholder throws a yellow sticky note – that contains their latest requirement – over your cubicle wall as they walk down the hallway). And sometimes the end users (an important stakeholder) are so focused around the user interface of the system, that suggesting changes to their user interface is the only way they know how to express their needs.

The advice you commonly hear regarding using the UML© for user interface modeling ranges from “don’t do it” to (at best) “create a User Experience (UX) model”. The UX model as traditionally described is good for simple situations, but with the advent of more modern, complex UI presentation options, the traditional UX model’s utility begins to reach its limit quickly.

I was pleased to find an elegant answer available in a little used area of the UML© that does not get delved into deeply very often…Read more