How sizing stories (points, t-shirt sizes, days & hours) is more than just Numberwang.
For (digital) agencies who use agile techniques for managing the design and development process there are some added complexities hidden in the abstractions of the story sizing.
Depending on the nature of the development project, a typical agency team might run the gamut of disciplines, from Interaction & Visual Designers, working in Illustrator and Photoshop through to Python engineers coding in Vim and living in the command line. And each with a (subtly) different understanding of the complexities involved.
Planning poker is the technique of getting multiple people on the team to independently size user stories, whilst trying to avoid the risks of ‘anchoring’. It’s a great method for driving cross discipline understanding of those tiny assumptions that can threaten to derail a project further down the line.
Which looks something like this: Sat in a circle, post-it notes scattered across the floor and walls, someone is describing a level understanding of a particular user story — it’s pretty simple on the surface “As a user I can sign-in to the platform, so I can register to use the service”. People scribble on the post it notes, using the Fibonacci sequence to size stories based on the relative complexity involved for the UX (interaction and visual design) and technology teams. After a few seconds everyone stops writing and holds up their post-it notes. It’s near the start of the meeting so people are still getting a little warmed up, even so the variance in the numbers is quite high. Not just between disciplines but also between team members who work in the same area. This is where the interesting bit starts.
The discussion that follows is the bit I find fascinating. The cases where someone in tech misunderstands the complexity of a design challenge or someone missing the difficulty of integrating with a third-party (“it’s just an API call”) is understandable — that’s why we are doing this as a cross disciplinary group. These are easy to flush out and correct.
The real area of interest is where people explain the assumptions behind the scores they’ve given. At this point we are into the details, and it’s great for the momentum of the project. Weeks of thinking, sketching and notes come tumbling out in the conversation — no amount of ‘annotated wires’ can accomplish the benefit of someone challenging why “that’s only a 3".
Capturing these assumptions is key — they make up the real scope and difficulty of a story. Often it’s also the risk factor that you’re gathering “I gave it a 21 because we just don’t know exactly how that’s going to work”. Whilst all forms of planning and project management are probably inherently flawed, you’re unlikely to get this level of collaboration and discussion whilst scoping out a typical waterfall build.
Agencies running agile are usually working with more constraints than a development shop. The client will probably have a fixed budget and timeline, so the only area of flexibility is scope. Whilst the aims of the project are (hopefully) going to be clearly documented and contractually agreed, these small instances of scope and the relationship between a ‘must’ and ‘could’ are the area of flex that teams are going to need deal with the reality of ‘unpacking a story’ and finding it’s more of a nightmare than a fairy tale. But that’s probably something to add to the backlog for another post…
2013-09-30 11:39:00 GMT permalink
2013-09-27 17:38:32 GMT permalink
2013-07-18 11:35:00 GMT permalink
2013-07-07 21:26:38 GMT permalink
2013-06-13 12:02:08 GMT permalink
2013-02-08 11:33:33 GMT permalink
2013-01-27 23:57:00 GMT permalink
The marginal gains of innovation.
Innovation in digital advertising.
Innovation in advertising.
Innovation.
How do you create an environment and attitude that allows people to innovate on a daily basis? Is it possible to create a culture of innovation?
There’s an increasing tension pulling at the commercial web. The commercial web being that part of the internet that’s trying to sell you something - even if that something is as intangible as brand or an idea or maybe even an emotion. This commercial web is becoming ever more formulaic and codified. Measured in an analytic sense, but also in a careful way. There’s a pattern to campaigns, to exploiting social media with the big players. Facebook, Google and Twitter drawing more and more users and therefore advertisers into their orbit.
Pulling against that is something that dates from the old web. The web of the 1990s. A culture of the new, the different - embodied by the continued evolution of the semantic web, the constant pushing and poking at the boundaries of the browser by people trying to maximise what can be achieved with JavaScript, HTML(5) and a good idea. Creating the expectation, the necessity, that the web must continue to evolve and innovate. It’s a long time since advertising was just a great 30 second TVC or even a nice and shiny corporate web site, it’s the way you do business, how you answer tweets and how customers feel about you and your product. Everything is marketing.
If you believe this to be true, that innovation is the key to stepping beyond the confines of the formulaic web, and therefore, standing out and being noticed, then how as an organisation do you make this one of your goals. Can you codify innovation? Make it reproducible? Isn’t that just like planning to be spontaneous. For teams involved in creating for the commercial web, innovation can not be something that happens in a vacuum, away from results - the formulaic, measured web has seen to that. This isn’t a story about “being brave enough to fail”. Client success isn’t a nice to have.
We seem to wrestle with this most days at work. I certainly don’t have all that many answers. Yet. But I’ve noticed that the most innovative projects I’m involved in have thse ingredients.
1. Be a team
Not just a group of people who happen to be free at the same time and who the resource manager and producer have cobbled together. That might be how the team gets selected, but it needs to evolve quickly into a genuine team.
2. Iterate
The big idea is great. Someone probably needs to have one at some point in the process, but that’s really just a beginning. Innovation isn’t the eureka moment. Or rather it’s not one big eureka moment, but normally hundreds of tiny innovations, back to back to back. Build something, make it better, change it, test it. Improve it. Some of the most innovative projects I’ve worked on recently haven’t really worked all that well right up until the last minute. There’s no such thing as getting it right - it’s a case of keep making it a little less wrong.
3. Be open to the marginal gains of innovation
There are opportunities to innovate across a whole spectrum of disciplines. The most effective innovation might come from the way you change the hosting, deploy your code, manage your daily scrum or prototype the user interactions. Nobody knows where this is going to come from, but it’s important to recognise any opportunity for innovation and grab it.
2013-01-19 00:44:17 GMT permalink