There is an interesting discussion on the kanbandev Yahoo Group exploring how best to plan and track UX work that impacts all of the features of a product. This would certainly impact the regular flow of the team if some UX work was going to have to be switched live on Day X. There are a number of constraints that Jose shares:
- UX people are part of the team, their work must be visualised with the rest of the team
- UX workflow is different to the user stories, no dev necessarily as it may just be investigation for future stories
In some respects you can leave a UX task like this on the board for a long time. Similar to an extended Sprint Zero.
I think a whole product UX revamp can still be broken down into manageable chunks such as Phase 1 / 2 / 3 / etc. You could then decompose that further into Design, Validation, User Testing, etc. Rolling out all of these changes on Day X can still be achieved although it would be difficult to batch up all of that work. Not to mention the waste as it sat there in the source code, unavailable to users.
- use feature flags to roll out features one at a time and get feedback from beta customers
- capture the value behind this feature flag until all of the features are ready to switched on
- keep the whole UX revamp story on the board in a different class of service, visibility is key for the whole team
- split out cycle time for this class of service so it doesn’t impact the rest of the board
Fun times revamping the whole UX for a product!
Speaking of which, GreenHopper 5.9.1 is available today. Our team has been hiding features from mainstream customers and only making them available for our beta customers. We slowly role new features out to all customers as they ‘solidify’ – not the whole product at once, although over time it will end up in a whole product UX revamp. So, I understand where Jose and the others on kanbandev are coming from.